Hello,
the std::optional as it is today has an overhead flaw with the additional bool in the implementation to check if a value is there. In a lot of major and important cases this is suboptimal. (It is necessary for the general case).
Principal example are pointers which have a NULL that is traditionally used to mark them as "not value".
Pointers in particular are a bad example, because if you need
- "A thing that maybe holds the address of an object, or maybe doesn't (and we physically represent the latter state by all-bits-zero),"
then you can just use `T*` directly. You don't need the `optional` part at all.
And C++26 introduces `optional<T&>` with the same semantics and physical representation.
You seem to want to make it so that an engaged `optional<X>` holds an X without some particular value, and a disengaged `optional<X>` holds an X with that particular value. That's never going to fly, because the point of a disengaged optional is that it does not hold an X. A disengaged optional<X> should be cheap to construct (notably it should not call the user-defined `X::X()`) and cheap to destroy (notably it should not call the user-defined `X::~X()`) — because a disengaged optional<X> should not hold an X to begin with!
There is a way to do it, even while keeping ABI-compatibility: it's called `tombstone_traits`. This was covered in 2017 and 2018:
It will probably never come to the Standard Library, but everyone who cares knows how to implement tombstones and is capable of doing it if they need to.
AFAIK, `tombstone_traits` has one downside even in C++26: since it relies on bit-twiddling, it's incompatible with `constexpr` evaluation. The STL's `std::optional` is usable at constexpr time; a tombstone-enabled `optional`, as far as I know, is not. But I haven't looked at the problem since ~2020, so I could be wrong about that by now.
–Arthur