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

> generate a quite good proposal

A proposal was generated, calling it "quite good" is subjective - I
personally wouldn't consider it "quite good." It's on the right track,
but it's missing a lot of key pieces that would help it be a better
proposal. On top of missing pieces, it fundamentally isn't the right
approach for WG21 because it breaks ABI and thus could never be
accepted even if it was a good paper in every other way.

> I also use a car to get from A to B and do not walk to every destination by foot as normal people do.

Please refer to the email you are replying to, I am encouraging you to
use AI as a tool. I think you missed that part.

> that is not my problem

If you plan on submitting a paper to a ISO working group you are
subject to the rules of ISO. Committee politics also matter, people
will be more inclined to support your work if it is high quality as
opposed to AI slop.

> Not everything has to be in the standard

Exactly. I have my own sentinel optional class, as have places where
I've worked. It is a useful thing to have, but standardizing it is a
different question. Most importantly: It doesn't replace
std::optional.

Jeremy

On Sun, Apr 5, 2026 at 1:44 AM Peter Neiss via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hello Jeremy,
> progress is ALWAYS AGAINST the masses, not with them. If you they dont like that in 2026 I can use AI to generate a slim_optional class that is BETTER in EVERY technical aspect in 2 hours and generate a quite good proposal with reference implementation, benchmark, etc than that is not my problem. I also use a car to get from A to B and do not walk to every destination by foot as normal people do.
> The implementation of std::optional is suboptimal and does not follow the zero cost abstraction principle. I personally never used optional with pointer types, as will a lot of other people and with good reason. But i want to use a good optional type for having a better interface even with pointer types.
> The ABI issue is real. I will rename my type as slim_optional and provide a free license in the future. Not everything has to be in the standard. The ISO rules for AI are quite reasonable and good. I want to see a better C++ and AI tools can help tremendously.
> Yours,
> Peter
>
> Am So., 5. Apr. 2026 um 04:48 Uhr schrieb Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>:
>>
>> > was it considered to decouple symbol mangling from the language
>>
>> Mangling is decoupled from the language, in that the standard doesn't
>> say how mangling should be done and the term "mangle" does not appear
>> in the standard.
>>
>> > For example, in this case optional<X> would still be mangled as before while optional<X, Y>
>>
>> This can be achieved by adding a class template for the two-parameter
>> version and leaving the existing one unchanged
>>
>> On Sat, Apr 4, 2026 at 6:28 AM Andrey Semashev via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > On April 4, 2026 1:56:39 PM Jonathan Wakely via Std-Proposals
>> > <std-proposals_at_[hidden]> wrote:
>> >
>> > > I only read the abstract, but how does changing the optional class template
>> > > from one template parameter to two template parameters provide complete
>> > > backwards compatibility? It means optional<X> has a different mangled name,
>> > > and so it's an ABI break.
>> >
>> > Unrelated to the proposal, but was it considered to decouple symbol
>> > mangling from the language? For example, in this case optional<X> would
>> > still be mangled as before while optional<X, Y> (for non-default Y) would
>> > be mangled differently. This could be achieved with a vendor-specific
>> > attribute. In terms of standardization, this would allow more extensions to
>> > existing standard types.
>> >
>> >
>> >
>> >
>> > --
>> > Std-Proposals mailing list
>> > Std-Proposals_at_[hidden]
>> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals