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
>