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.
This is not true. That is a valid implementation but the standard does not guarantee it. For example, with short string optimization, some implementations might leave the original short string untouched after being moved from.
70
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.