On Sun, Feb 12, 2023 at 4:06 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Thu, Feb 2, 2023 at 5:49 PM Thiago Macieira wrote:
>
> > > This new feature could be kept simple, or tt could made be very
> > > complex with extra parameters to do stuff like:
> > > * Prevent reentry by other threads but not by the same thread
> > > * Prevent reentry by the same thread but not by other threads
> > > * Prevent reentry by all threads except the one with the specified
> > > thread::id
> >
> > You've mostly implemented this already as library solutions.
> >
> > So please explain why you think this should be a core language change. What
> > can the core language do better than a library solution could?
>
>
> I haven't got a library solution. Needing to add 'atomic_flag' objects
> to your classes and functions, and then manipulating them as
> appropriate, isn't simple and straight-forward, and it's not a
> 'library solution' in the simplistic sense of just including a header
> file and then using an encapsulated class.
>
> I'll try to explain what I mean here by making a comparison with
> another of C++'s features. In C++, we can have a static object inside
> a function, and even if our program is multi-threaded, the
> aforementioned static object will only ever be constructed once (and
> the other concurrent threads will wait for it to be
> fully-constructed).

The thing about your analogy is that function-static was part of C
before ISO standardization. C++ inherited it, and therefore when C++11
started to get proper threading support, it inherited a *problem*.
Namely, that a bunch of code might be subtly broken (or already was,
since threading existed in real systems long before C++11), since C++
has much more complex initialization than C does. So they made a
(non-trivial) change to ensure that such code wasn't subtly broken.

The circumstance you're talking about is very different. It's not a
choice between a subtly thread-unsafe feature and one that is
thread-safe. It's a choice between the status quo and having a very
specific, very specialized tool. Not to mention, you don't have a
choice; all function-static initialization is thread safe, whether you
need it or not. It's not like there's an attribute that can turn it
off or something.

What you're talking about needs a positive reason why it needs to
exist in the language. A discussion also needs to be had with how it
interacts with function pointers, `noexcept`, and the like.