> On Sat, Jun 19, 2021 at 7:17 AM Uecker, Martin via Liaison
> <liaison_at_[hidden]> wrote:
>> For compatibility, there are two things required:
>>
>> 1. Compatible syntax for headers
>> 2. ABI compatibility
>>
>> Regarding the first point, in C we have the atomic_XXX types and
>> also the _Atomic(T) type specifier (C11), which were both designed
>> together with WG21 with compatibility in mind. The only thing which
>> still was missing is the _Atomic(T) macro in C++. This seems now part
>> of C23++ [1]. So the compatibility story seems finally complete
>> and we can now write things like this (thank you WG21!):
>>
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>>
>> #include <stdatomic.h>

I'd put the #include outside of the "extern C" bracket.

>> void foo(_Atomic(int) *x);

Before C++23, you could have written

void foo(atomic_int *x);

instead.

>> With respect to ABI, there is still the issue that _Atomic(T) types
>> are not compatible between implementations even within C++:

The ABI story of atomics is a sad one, but nothing the language
standard can fix.

>> Finally, there is the _Atomic qualifier in C which is currently
>> a different way to specifiy the same type as _Atomic(T).
>> From the C side, this is problematic as it is at the same
>> time completely useless because it provides no new functionality
>> and confusing as it does not work in he same way as any
>> other qualifier.
>>
>>
>> But the _Atomic qualifier in C also has no impact on C/C++
>> compatibility at all as it is not supported in C++ (similar
>> to how std::atomic<T> template syntax is not a compatibility
>> problem as this is not supported in C).

I'm not aware of any effort that would make "_Atomic T" valid
in C++ (nor would I be in favor of such endeavor).
The compatibility advice is to use "_Atomic(T)" instead.
So, C is free to do whatever it wants with "_Atomic T".
However, if C comes up with a new meaning of "_Atomic T", we
should still understand whether that syntax would be agreeable
to C++ for that new meaning.

For example, I'd probably prefer a library macro
"_Atomic_ref(T)" for the C/C++ compatibility story over
supporting in C++ "_Atomic int *" with the meaning "atomic access
to a plain int", including core language conversion from "int*"
to "_Atomic int *".

Jens