Standardization is not engineering. Standardization is tedious and boring (for most people). If you are looking for a fun hobby, this is not for you. It could be a fun hobby to write about these ideas in a blog post (like a lot of people do).

Just because you *can* implement something does not mean it *should* be in the standard. If you want to propose something it is your job to 1) motivate the proposal, 2) show how it is useful, 3) explain how it will improve a lot of code, and 4) how it will affect other parts of the standard. It would then be sufficient to state that there is an implementation. It would be much better if the implementation had been in real use for a couple of years to figure out all the things that are wrong with it. Or alternatively you don’t need an implementation if you can point at the same feature in another language.

An implementation by itself is useless. Standardization is not engineering. Standardization of the C++ library mostly standardizes common behavior, i.e. something that is used in real code bases.

> On Nov 27, 2025, at 12:33 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Wed, Nov 26, 2025 at 11:14 PM Oliver Hunt wrote:
>>
>> No one can provide meaningful feedback to a proposal if there is no proposal.
>
>
> It's funny, I've been on this mailing list a few years but only in the
> last few days did I realise something. . .
>
> After I finished high school, I went to study electronic engineering .
> . . these were my kind of people . . . stripping wires in the lab and
> hooking up 555 timers to 7-segment-display encoders. Blowing the fuses
> in our ammeter once in a while.
>
> Then I went to go live in Asia for a while . . . and later I came back
> home and went to study computer science. These were __not__ my kind of
> people.
>
> It's funny, even though my strongest suit in electronics was always my
> programming skills, I still aligned much more to the stereotypical
> personality of an engineer.
>
> I think most of you folk on this mailing list are 'computer
> scientists'. You want stuff written down -- This should do This, That
> should do That. But I think an engineer -- I'm speaking
> stereotypically of course -- would much prefer a working prototype to
> play around with and come back and ask questions later.
>
> In my own mind -- and yes I realise that I speak about one unique mind
> -- what I've give you all so far is more than enough to get talking
> about this. You have my original paper, you have Arthur's blog which
> is decent, and for the love of the sweet mother of divine Jesus Christ
> and the twelve apostles, I've given you a full working prototype. You
> can literally go on GodBolt and play around with my new compiler
> feature.
>
> Oliver I know we've been back and forth a few times, and as I've said
> to you I'm trying to accept with equanimity the contrast in our
> personalities, but sometimes I'm left thinking, "Why does this guy
> need the blatantly-obvious written down in black and white all the
> time when the code is very clear?". I mean I think my GodBolt link
> tells ya nearly everything you need to know -- you can edit the code a
> little, see what it does, add another base class and come back to me
> with "I notice it does X, but shouldn't it do Y instead?" -- that
> would open up discussion.
>
>
>> And voila you’ve just made the list useless for people who are willing to actually do the work you are at this point intentionally refusing to do.
>
>
> I'm preparing a paper on "std::chimeric_ptr" but I want more
> discussion on it first -- particularly I want to disassemble Thiago's
> argument that it's only use is to compensate for bad programming. I
> want to unravel that before putting a lot of work into writing
> something that I might disagree with later.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals