No, those the two concepts are related. mp::opt<> requires the user to
designate an impossible value, but it may not be available.

In my idea, std::optional still carries a boolean. But the boolean no
longer affects whether the destructor, move assignment, or move
constructor destroy the carried T; optional::operator bool.

On Sat, 2025-06-07 at 13:26 +0200, Robin Savonen Söderholm via Std-
Proposals wrote:
> Sounds like: https://github.com/mpusz/opt
>
> // Robin
>
> On Sat, Jun 7, 2025, 13:24 Jan Schultke via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > I don't think it's worth the effort if it cannot work for
> > fundamental
> > types, and the ABI for std::optional is set in stone. Ideally, we
> > would be able to say that std::optional<X*> where nullptr stores
> > the
> > empty value, or std::optional<int> where -1 represents an empty
> > value,
> > etc.
> >
> > Those things seem feasible with std::expected with a bit of library
> > support. We could have something like
> >
> > > std::expected<int, std::nonvalue<-1>>
> >
> > Which would use the value "-1" to represent an unexpected object.
> > This
> > would also not break any existing code since it would use novel
> > types
> > and a novel protocol, even in the case of fundamental types.