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_at_[hidden]> 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_at_[hidden]> 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
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>