At last, someone understood me, maybe I wasn't so terrible at expressing myself.

I should have called out the sentinel idea though and explained it's something else.

On Sat, 2025-06-07 at 15:03 +0100, Jonathan Wakely via Std-Proposals wrote:
I think Avi's suggestion is a subset of that idea. You don't necessarily need a sentinel (or "tombstone") value, you can still keep the separate bool member for the "has value" flag. But you would always construct a value even when the flag is not set, so that special members don't need to check the flag. 



On Sat, 7 Jun 2025, 14:11 Jeremy Rifkin via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
Hello,
I’ve seen this sort of thing before as a “sentinel optional” where one value is set aside to represent null (typically the min or max value for integer types). It would require a customization point to provide sentinel values for other types. I’m not sure this is a good fit for the standard library but I’ve found it useful before. It tends to be a fairly small optimization relative to std::optional.

Jeremy

On Sat, Jun 7, 2025 at 04:33 Avi Kivity via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Consider std::optional<T>.

The move constructor has to check if the moved-from optional is
engaged, and if so, move-construct the contained T. Similarly other
special functions have to take actions conditionally. The destructor
has to check if the optional is engaged and only invoke T::~T() if
that's the case.

However, if we had a way to cheaply create a T, we could use that and
avoid all the conditionals. Let's say the protocol is


template <typename T>
struct construct_empty {};


template <>
struct construct_empty<my_lovely_type> {
    static void operator()(my_lovely_type* where) noexcept;
};

If construct_empty is specialized for a T, then optional<T>'s default
constructor could initialize the contained T whether or not the
optional is engaged or not, and all the conditionals for the special
methods would disappear. For trivially constructible standard types,
construct_empty would do nothing. For many standard types, we could
call the default constructor. The user could opt-in for cheaply
constructible user types, often just calling the default constructor.

This seems related to trivial relocation, just from the other side as
it were. Maybe opt-in should also be via an attribute.

--
Std-Proposals mailing list