Am Freitag, den 11.02.2022, 17:52 -0500 schrieb Robert Seacord via Liaison:
> I agree with the direction of this discussion so far. Does this
> initialization problem only affect thread_local or does it affect other
> storage classes as well?

I don't think there are other major issues.

In general, as someone suffering from C <-> C++
interoperability issues myself, I think it would be
far better for the users if extern "C" evolved
into a proper foreign language interface similar
to what other programming languages have.

For example, it could directly support complex types
or atomics and rewrite it into corresponding C++ types,
and it could ignore the restrict qualifier.
If we really wanted to make this good, we could
even rewrite VM-types transparently convert into
mdspa
n on the C++ side. All this could be done
without the risk that pure C++ code is affected
in any way,
and at the same time the C used in
these interfaces would not need to be so constrained
so much.

All this seems easy to implement. Compilers could
maybe just announce what C version they support
here.


Martin



> Thanks,
> rCs
>
> On Fri, Feb 11, 2022 at 4:44 PM Jens Maurer via Liaison <
> liaison_at_[hidden]> wrote:
>
> > On 11/02/2022 22.39, Corentin wrote:
> > >
> > > On Fri, Feb 11, 2022 at 10:33 PM Jens Maurer <Jens.Maurer_at_gmx.net
> > <mailto:Jens.Maurer_at_[hidden]>> wrote:
> > > 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.
> > >
> > >
> > > Don't we need to allow extern "C" static? Afaict this would be novel
> >
> > extern "C" {
> > static int x = 1;
> > }
> >
> > works with gcc today.
> >
> > Jens
> >
> > _______________________________________________
> > Liaison mailing list
> > Liaison_at_[hidden]
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > Link to this post: http://lists.isocpp.org/liaison/2022/02/0976.php
> >
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]rg
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2022/02/0977.php