On Sun, Apr 5, 2026 at 10:14 AM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

> 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:
>

Er, brain fart: "While keeping the same *name-mangling* for `optional<X>`
that it has today."
The *entire point* of the feature is to break ABI-compatibility — to make
`optional<X>` have a smaller memory footprint.
Maybe what I could have said here was "while keeping C++26-conformance
(minus constexpr-friendliness)": while no existing STL vendor could use
this technique (because ABI), a *new* STL implementation could use it to
get an advantage over the existing ones, without breaking conformance
(modulo constexpr-friendliness).


> 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
>