Nice to see some interest. I have restructured the library to be a third
party library with free MIT license. It is now slim::optional and only for
types that can provide a sentinel type.
I am not the right person to drive a standard proposal, although I would
like every C++ developer to have easy access to my library.
This is it:
https://github.com/PeterNeiss/optional

Have fun programming (even with AI)
Yours,
Peter

Am Mo., 6. Apr. 2026 um 02:36 Uhr schrieb Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]>:

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