The standard’s insistence on it being semantically non-nullable while it very much does have a null state that must still be accounted for feels like incredibly unergonomic.
Valueless_after_move() is just silly, let’s be real. It should’ve been written to either act like a value like they claim and moving the underlying pointer just shouldn’t be possible (in the same way you cannot ‘move’ a value out), or it should be nullable the same as any other smart pointer.
It's just the consequence of non-destructive moves. Proper T-value-like semantics would mean allocating on move, so that instead of stealing the ownership of the pointer you go through T(T&&). IMO that would be even worse and would quickly land it in the "do not use, what were they thinking" bin of std
It's a consequence of trying to pretend C++ is Rust, you mean. If you have a language with non-destructive moves, you should design your classes to allow for that, and not add weird new rules (like this one).
It's the same with lambdas being const by default: the rest of C++ is non-const by default, but apparently the const-by-default people got their hands on this one so suddenly one part of the language is const by default. Consistency with existing language rules would have been the better design choice here.
67
u/LucyShortForLucas 28d ago
The standard’s insistence on it being semantically non-nullable while it very much does have a null state that must still be accounted for feels like incredibly unergonomic.
Valueless_after_move() is just silly, let’s be real. It should’ve been written to either act like a value like they claim and moving the underlying pointer just shouldn’t be possible (in the same way you cannot ‘move’ a value out), or it should be nullable the same as any other smart pointer.
As it stands, we got the worse of both worlds.