On Sat, Apr 4, 2026 at 6:19 AM Peter Neiss via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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:
https://www.youtube.com/watch?v=MWBfmmg8-Yo&t=2464s
And it's implemented in a few places, e.g. foonathan/tiny
<https://github.com/foonathan/tiny?tab=readme-ov-file#tombstones>.
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