I’m still not sure what chimeric_ptr does, much like your last email about a new feature you have not provided even the most rudimentary shadow of a proposal.

I do not understand why you are absolutely unwilling to provide specifications for your features, but at this point you are functionally DoS’ing this list, to the extent that I am likely to unsubscribe as your emails have made it overwhelmingly worthless.

Your behavior has the effect of denying use of list to people who are willing to actually putting the work in as it is already caused others to drop from the list.
As I have said previously you are not showing any respect for the time of others on the list.

* Implementations are not proposals
* Implementations are not specifications
* Implementations that are not covered by the ISO IP policies that as an ISO member you have agreed to follow cannot be read by others the list, so that even if they were remotely acceptable as a substitute for a specification - which again: they are not - people can’t read them.
* Please use your identity, as in the ISO registry, when sending these emails - a pseudonym is inappropriate for an iso member on an iso list, if nothing else it lays a foundation for astroturfing.

—Oliver

> On Nov 21, 2025, at 11:56 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Fri, Nov 21, 2025 at 7:30 PM Thiago Macieira wrote:
>>
>> So, what you're saying is that it uncrappifies crappily-designed APIs?
>>
>> I think that people responsible for the crappy APIs should revisit their
>> design choices in the first place.
>
>
> Or alternatively they can avoid an ABI break until the next time they
> increment the major version number.
>
> std::chimeric_ptr can be used for such a purpose, i.e. to avoid an ABI break.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals