On 11/02/2022 22.20, Corentin via Liaison wrote:

>
>         I think the most intuitive behavior is if
>
>         extern "C" thread_local S foo;
>
>         behaves just like _Thread_local would do in C and a C++ type
>         that requires non-trivial initialization would simply not
>         be allowed, i.e. it behaves like _Thread_local in clang
>         in c++ mode.

Sounds good to me.

 - Survives WG14 making thread_local a real keyword.

 - Requires no collaboration from WG14.

 - Your header shared between C++ and C already ought to use 'extern "C"',
so this reduces the footgun surface.

 - thread_local in C++ with dynamic libraries is already a nightmare
(dynamic initialization order, squared), and this nicely sidesteps the
problem.

 - If C++ wants to do something on the C++ side (e.g. constdestroy or so),
it can do so at its own pace.

>     I agree. Why would you be trying to use a type with non-trivial init in common code defined in a header, but so that it does different things in C and C++? If you need non-trivial init, define the code in a separate C++ transition unit, not in a header.
>
>
> But by that logic, do we want to change the grammar of C++ for this narrow scenario?

We're not changing the grammar.  We're just adding a paragraph of restrictions
for thread_local.  That seems palatable, given that 'extern "C"' already
causes restrictions for other areas of the C++ syntax.

Jens