On Tue, Feb 9, 2021 at 2:57 PM Joseph Myers via Liaison <
liaison_at_[hidden]> wrote:

> On Tue, 9 Feb 2021, Uecker, Martin via Liaison wrote:
>
> > One way forward for C could be to decouple the qualifier
> > and the specifier and make casts of non-atomic types
> > possible. _Atomic(T) would then be an _Atomic-qualified
> > type which has additional properties not implied by
> > the qualifier (stricter alignment) and which is compatible
> > to C++.
>
> Since the two forms of _Atomic are just alternative notation for writing
> the same type (and so are the atomic_* names in stdatomic.h), changing
> that now would be clearly incompatible with existing code and I think very
> much a bad idea.
>
> 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. But T and std::atomic<T> can't reasonably always
have the same representation, since that would force locks to be used where
they are avoidable, which certainly many of us agree is a bad thing. So we
can't have _Atomic T both work as a proper qualifier and be the same
as std::atomic<T>. 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.

A further complication (or simplification, depending on how you look at it)
is that the ABI story here is currently badly broken for everything but
simple types with size == alignment. The upside is that we can probably
change more than one might expect, so long as we leave the simple (and by
far most common) case alone. Everything else is largely broken and
hopefully unused anyway.

All of which is an argument to properly discuss this at a meeting ...

Hans