Am Mittwoch, den 10.02.2021, 17:41 +0000 schrieb Joseph Myers via Liaison:
> 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.

It is an irregular use of a syntactic construct, which is also
redundant. And the wording makes it even worse: We call
it a qualifier. But then we say we do no mean it when we talk
about qualified types. This is is very confusing for a reader
of the standard. If do not want to change it we should
deprecate it.

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

A qualifier is exactly what is needed if you want to
express atomic operations on non-atomic data as it has
exactly the right right semantics. Qualifiers affect
accesses to lvalues and follow the right conversion
rules. So the idea to use the existing _Atomic
qualifier for this seems reasonable to me, because
it would also make it non-redundant and fit well
into the language as a regular qualifier. A lot of
confusing wording and special cases could just be
deleted from the standard text.

The question is whether it can be made compatible or not.

If the problem is only alignment, then I think this could
be made backwards compatible (as pointed out in my
other email).

But I am not sure what to do with implementation that
include locks into atomic types. Maybe they would then
just not support the new semantics.

The alternative is a new qualifier.

Best,
Martin