No, this is a separate idea (Rust has this sentinel optional).

With my idea, the user does not designate a sentinel value (for
example, for std::optional<int> one does not exist in general). Instead
the user (or standard) designates a value to be used when the optional
is disengaged. This allows (e.g.) the move constructor to uncondionally
move the carried T instead of dancing around it.

On Sat, 2025-06-07 at 08:11 -0500, Jeremy Rifkin via Std-Proposals
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.
> >