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