On 19/06/2021 14.39, Uecker, Martin wrote:
> Am Samstag, den 19.06.2021, 14:24 +0200 schrieb Jens Maurer:

>> 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 *".
>
> This was my original idea, although I now think it
> might be better to deprecate _Atomic and introduce
> something new. For C, a qualifier seems to be
> exactly the right mechanism on the language level.

Maybe; that's for WG14 to decide.
(From a type perspective, I agree it feels a bit like
a volatile-qualified type.)

For C++, I'd much prefer confining "atomic" things to the
library, without modifying the core language.

It would be good to understand whether a macro wrapper
along _Atomic_ref(T) can feasibly map "T" to "_Atomic T"
("atomic reference" meaning in C), with T possibly being
an "interesting" type such as a pointer-to-function type.
I think alias templates can do that in C++.
An easy way out would be to restrict "T" to simple types
or typedef names.

> (I will also not argue against the use of templates
> in C++.) We could then add a _Atomic_ref macro if this
> makes sense.

The question is whether we can/should/want to have a standard-based
compatibility story for "atomic reference" or not.
We've recently made "_Atomic(T)" the compatibility advice
for atomic types in code shared between C and C++. Good.

Jens