On 12/02/2022 10.22, Uecker, Martin via Liaison wrote:
> 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.

So far, "extern C" imposes only additional restrictions
on the contained stuff (namespaces are ignored when
determining naming conflicts; thread_local supports only
types with trivial construction and destruction).
This seems plausible to me.

Changing syntax inside "extern C" is going one step too far
for me. Whether C++ wants to support "_Complex T" as an
alias for std::complex<T> should be a global feature, to be
decided on its own merits.

For atomics, my understanding is that the compatibility
story is already quite good, because you can write _Atomic(T)
in both languages.

For multi-dimensional VM-types, I'm not sure those can be
represented with an mdspan at all.

Jens