Am Samstag, den 19.06.2021, 21:57 +0200 schrieb Jens Maurer:
> 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.)

Yes, qualifiers have the right conversion behavior for
pointers, and it would do what all qualifiers do in C:
define access protocols to objects without affecting
the type itself.

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

This makes sense for C++.

> 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

Since _Atomic_ref(T) is basically a pointer the
corresponding C type would then be _Atomic T*.

But would we need to wrap it into a struct
for ABI compatibility?

> 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.

Mapping T to _Atomic T* can be done with typeof.

Adding a struct wrapper is a problem because of the
obscure rules for struct compatibility which C still
has. I am not sure we get this fixed in C23.

> > (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.

I am am also not sure. For me _Atomic_ref would be something
used mainly internally in a library, e.g. where an
external interface passes a data structure without atomic
types and then the library wants to apply a concurrent
algorithm on the existing data structure.

Martin