@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.
@namark Theoretically eveything is possible. C++ could add `extern "Rust" { <insert Rust code here> }` and say it's as safe as Rust now, but we know they won't do that, and that's not what people mean by safety in C++. Keeping compatibility with existing C++ source, libraries, idioms, etc. makes adoption of Rust's safety model way more difficult and likely impossible.
This isn't wanting the impossible in the absolute sense, because Rust has achieved Rust's safety level. C++ just can't go as far
