On Sun, Apr 5, 2026 at 4:01 PM Jeremy Rifkin via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> > generate a slim_optional class that is BETTER in EVERY technical aspect
>
> It's not, as was already explained.
>
> > The implementation of std::optional is suboptimal and does not follow the zero cost abstraction principle
>
> std::optional is a general-purpose container. As has already been
> explained, not all types and use cases have a sensible sentinel value.
> The design of std::optional does not violate the zero overhead
> abstraction principle: You pay for what you use.
>
> > I personally never used optional with pointer types
>
> Typically you would never want to use std::optional with a pointer
> type. A pointer is already nullable, a std::optional<T*> is odd
> semantically because it can be null in two ways. That may be different
> with a sentinel optional, but why use an optional at all and what if
> it makes sense to use a different sentinel value?

There is one case where it comes up: you have a template
function/class and you use an `optional<T>` with `T` being a template
parameter. Assuming there are no concept violations, instantiating it
with a pointer should be valid.

But this is where the whole `slim_optional` thing falls apart: if I
pass such an API a `nullptr` for the `optional<T*>`, it *should*
consider that to be an engaged optional. I passed a valid value of
type `T*`, so that is what it should hold, and all users of the
`optional<T*>` should treat it as holding a value. That is the correct
behavior.

If this were a `slim_optional`, it would not be treated as engaged.
Which would mean that you wouldn't be able to use such an optional in
template code as its behavior changes depending on whether `T` has an
unengaged value or not.