My suggestion on the WG14 reflector was to make _Atomic T ill-formed if
_Atomic(T) does not have the same representation as T, and equivalent to
_Atomic(T) otherwise. I think that would make it usable as a qualifier and
atomic_ref<> replacement. That didn't seem to go over well there, but
the reflector seemed to be a poor way to understand whether there was a
WG14 consensus for any of the options.

I think it provides enough compatibility with the status quo that it might
be an acceptable change by WG21 standards. That may not make it acceptable
by WG14 standards. It breaks only code that uses the type qualifier
notation for something that behaves very differently from a type qualifier,
and it breaks it loudly.

Making/keeping _Atomic T, _Atomic(T), and std::atomic(T) all synonymous
also works for P0943. But it would eventually require an alternate
atomic_ref<> solution for C, I think. And having _Atomic as an alternate
spelling for _Atomic() (that buys nothing except breaking C++
compatibility?) seems suboptimal to me.

On Wed, Feb 10, 2021 at 9:43 AM Joseph Myers <joseph_at_[hidden]>
wrote:

> On Tue, 9 Feb 2021, Hans Boehm via Liaison wrote:
>
> > We've had similar discussions before on the WG14 reflector. The concern
> > here is basically that if _Atomic were to be usable as a real type
> > qualifier that can be added to parameters, then _Atomic T and T should
> have
> > the same representation.
>
> Whereas in fact it's not a qualifier at all, other than purely
> syntactically (_Atomic T is an alternative syntactic notation for _Atomic
> (T)), and it's explicit in the C standard that references to qualified and
> unqualified types do not count _Atomic as a qualifier by default.
>
> > I think C really wants the type qualifier to work, since
> > it doesn't have atomic_ref<>. So something has to give, and we've had
> > different proposals about what that should be.
>
> Whatever system you might add for atomic operations on non-atomic data, I
> think making the syntactic-qualifier _Atomic into something semantically a
> qualifier would be an unreasonably incompatible way of adding such a
> feature.
>
> --
> Joseph S. Myers
> joseph_at_[hidden]
>