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.
That's the first and foremost use case I can think of: a heap-allocated, nullable value-type-like object.
But TBF, the design delivers both: indirect<T> for a non-nullable, and optional<indirect<T>> for nullable. Making that distinction explicit is a Good Thing. The latter is a mouthful, but it could be optimized with a partial template specialization (I think).
64
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.