Date: Sun, 5 Apr 2026 10:09:10 +0200
> 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 hard part is usually not generating paper slop, but doing your research
and coming up with a design that is sound. Your AI has failed to find
https://lists.isocpp.org/std-proposals/2025/06/14078.php for example, which
has some discussion on this issue and a solution that could work as a
non-breaking change that builds on std::optional.
In your paper, the wording is not phrased as a relative change to the
draft, has broken formatting and syntax highlighting, and is overall not in
a state that is worth reviewing. The performance benchmarks section
references a nebulous BENCHMARK_RESULTS.md file which you haven't attached,
and I'm not sure if that file even exists or is an AI hallucination.
When you brag about "vibing" the paper with Claude, I cannot trust any of
its contents to contain information that's not blatantly hallucinated, and
I cannot trust you to understand what's in your own paper, let alone fix
any technical issues in it or answer technical questions about it.
> 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.
>
AI only lowers the bar on the easiest part of the proposal process, which
is arguably not even a good thing because we already have more proposals
than the process has capacity for, and far more new features than can be
implemented within a year.
AI would have a much more positive impact if it was used for research,
review rather than clogging up the already tight bottlenecks with slop.
Using AI for review and research is more in the spirit of ISO rules for AI
as well, to my understanding.
> 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 hard part is usually not generating paper slop, but doing your research
and coming up with a design that is sound. Your AI has failed to find
https://lists.isocpp.org/std-proposals/2025/06/14078.php for example, which
has some discussion on this issue and a solution that could work as a
non-breaking change that builds on std::optional.
In your paper, the wording is not phrased as a relative change to the
draft, has broken formatting and syntax highlighting, and is overall not in
a state that is worth reviewing. The performance benchmarks section
references a nebulous BENCHMARK_RESULTS.md file which you haven't attached,
and I'm not sure if that file even exists or is an AI hallucination.
When you brag about "vibing" the paper with Claude, I cannot trust any of
its contents to contain information that's not blatantly hallucinated, and
I cannot trust you to understand what's in your own paper, let alone fix
any technical issues in it or answer technical questions about it.
> 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.
>
AI only lowers the bar on the easiest part of the proposal process, which
is arguably not even a good thing because we already have more proposals
than the process has capacity for, and far more new features than can be
implemented within a year.
AI would have a much more positive impact if it was used for research,
review rather than clogging up the already tight bottlenecks with slop.
Using AI for review and research is more in the spirit of ISO rules for AI
as well, to my understanding.
Received on 2026-04-05 08:09:26
