@GlowingLantern Such absolutist view makes the problem impossible almost by definition, so it's completely impractical.
Every lock can be picked, so is there no point having doors? If a door can't be guaranteed to be really locked, why upgrade from a piece of string to a steel padlock?
@kornel your argument is the absolutist one in terms of the language. Asking how to make C++ absolutely safe in regard to object lifetime management, one arrives at rust as the answer. Except then one realizes that nothing is absolute and the language is fundamentally flawed without the unsafe code, that is there are efficient and safe data structures that are impossible to implement with the hard requirement of absolute language level safety.
C++ could easily have a subset, sticking to which you can have exact same guarantees. At that point it just becomes a question of opt-in versus opt-out. I imagine when it gets to it, we'll also know a lot more about object lifetime management, and employ better abstractions and customization points.
@GlowingLantern@misskey.de
@namark C++ has a very firm stance on backwards compatibility. It's at the point where it won't even make changes that would slightly break unofficial ABI it never promised to have.
There is unsafety identified in existing C++ constructs, and they're incompatible with what Rust found to be necessary for its safety model.
Therefore, either C++ can't have Rust's safety model, or C++ has to change its backwards-compat policy. The signs point to not having Rust's safety model.
@kornel I can only see that being true from the point of view of applying the model to absolutely everything across the board. You want raw references or pointers to be borrowing, c++ says nope of course. You want a special borrowing reference? Nothing compatibility or ABI breaking there. It's just a matter of defining good fundamental abstraction in the language standard. Yes C++ will never have rust's model, it will more likely have a few new fundamental building blocks added with which you could implement rust's model as a library, and many other similar models.
@namark "it will more likely have a few new fundamental building blocks added with which you could implement rust's model as a library"
Google literally tried to implement that:
They've identified big obstacles to implementing this, including need for a different type of moves and destructors. Not as easy as new building blocks, because it touches so much of the type system and has complex semantics. They recommend adding borrowing built-in into the compiler.
@namark I recommend checking Rust's history of the borrow checker, from being scope-based (close too what could be done with a metaprogramming library), to being IR-based AKA "NLL", to Polonius project which tracks regions on control flow graph. Borrow checking is way harder than it seems. Even relatively simple code runs into issues that are either soundness holes, or become freakishly complex to prove.
@namark And given that borrow checking has tricky cases that are either unsafe or require writing a subset of a prolog compiler inside your C++ compiler to solve, I expect C++ WG to choose holes every time.
They've failed even in easy cases. They could have made std::optional UB-free, but chose not to. They could have added pattern matching or ADT instead of std::variant contraption, but chose not to. C++ could have been copying Rust's safety for 2 releases now, but went with old habits instead
@kornel I guess I'm a heretic, but to me the UB of optional is a feature, and I don't see variant as a standing for pattern matching, to me it was primarily presented as an alternative to traditional dynamic polymorphism, where you would naturally restrict yourself to common denominator interface, not branch on different interfaces.
You seem to overestimate the scope of features in c++. They are usually rather narrow and focused, with a purpose to get a certain specific thing right, not chase the latest fads in programming.
@namark ADTs are from 1970s, hardly a latest fad. They turned out to be a very useful language primitive that made several special-case features unnecessary.
Both C++ and Rust are 100% safe when the programmer writes correct code. The thing I don't see in C++ community, is accepting that programmers will write bugs and use things incorrectly. 40 years of complaining at bad and lazy programmers haven't worked.
std::optional is unsafe when used incorrectly. Option is safe when used incorrectly.
@kornel since when is ADT and pattern matching the same thing?
And oh yes of course let's use it wrong and still make it work. Lets design a drill that is monkey proof and apply it across the board wherever any holes need drilling. It's actually an single exoskeleton that doesn't fit most applications but we have change the world to make it fit.
That philosophy is flawed (yet surprisingly common), it presumes the language developers are better than anybody else and found the holy grail of programming. Many such holy grails had come and went. In time the hordes of illiterate apes whose incoherent scribbles rust is so desperately trying to contain will come up with superior programming patterns that it never even anticipated and completely deprecate it.
C++'s philosophy is to respect its userbase.
@namark In Rust pattern matching is the "UI" for ADTs, so they go hand in hand. Pattern matching is a fad from 1957.
Your triade about apes/scribbles/grails/wtf is just empty emotional posturing.
The data is that the respected C++ userbase keeps writing memory bugs. GOOG and MSFT (who are not amateur coders) report ~70% security issues due to it.
Rust eliminates majority of them, most by construction. Makes real-world difference, e.g.: https://github.com/rust-fuzz/trophy-case (panic/unwrap == C++ exception)
@kornel There were no programming fads in 1957, you need pop culture to have fads.
I critique your philosophy with a bit of flare.
Tou dismiss it as emotional posturing.
It's Super Effective!
GOOG and MSFT, of course, as a practitioner of the discipline I have much respect for these cesspools of snake oil. It's not like they accumulate all the bad practices over the years in giant indivisible monoliths, and then try to find ways to regex replace some stings in them to fix all the problems, which would explain the mindset in the writeups you linked here.
You will make a real world difference when you implement a system of same complexity and objectively proove it more stable and otherwise equivalent, not by counting all 0 memory errors in a language that was designed to eliminate memory errors. And then on top of that somehow prove that a similar thing can not be achieved with same effort re-implementation in modern C++. Until then it's not a real-world difference, it's marketing.
