On Thu, May 25, 2023 at 4:01 PM Phil Bouchard via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On 5/25/23 15:56, Jonathan Wakely wrote:
> >
> >
> > On Thu, 25 May 2023 at 20:43, Phil Bouchard via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> > wrote:
> >
> > Because either it wasn't available with GCC 9, _GLIBCXX_USE_CXX11_ABI=0
> > or the simple fact atomic operations still doesn't fix the defective
> > reset() call.
> >
> >
> >
> > So what are you advising the committee to do about that?
>
> To add some thread-safe macros so all containers, smart pointers and the
> entire library becomes thread-safe.

Um, no. That would break the performance of any number of applications
that don't need thread safety or have handled it properly themselves.

If you want a language where you can write anything and the system is
designed to account for every possible contingency, that's fine. But
that's not C++, nor is it going to be, nor should it become that. What
you want is a higher-level language.

And I'm pretty sure no language makes *everything* in its standard
library thread-safe.

This really feels like, "I got bit by a bug someone else put into
their code, so I'm going to assign responsibility for it to a third
party who now should help the second party make their code better."
Getting hit by bugs in other people's code isn't great, but this just
isn't a reasonable response to that.