Date: Fri, 11 Feb 2022 22:33:25 +0100
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
>
> 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
Received on 2022-02-11 21:33:28