[PATCH] D125919: Drop qualifiers from return types in C (DR423)

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

> I disagree with the assessment that _Atomic behaves exactly like a qualifier. It *should* (IMHO), but it doesn't. C allows the size and alignment of an atomic type be *different* from its unqualified version, to allow for embedded locks and such. Because the size and alignment can be different, to my mind, _Atomic int and int are different types in the same way as _Complex float and float -- the object representations can (must, in the case of _Complex) be different, so they're different types. The same is not true for const, volatile, or restrict qualifiers -- those are required to have the same size and alignment as the unqualified type.

I think our apparent disagreement here is rooted in something quite simple: you seem to be assuming that a qualified type by definition cannot have a different size and alignment from the unqualified type, and I think that's a property that's *guaranteed* for the CVR qualifiers and merely *happens to be true* for our current set of extended qualifiers, and only really because we don't represent `_Atomic` as a qualifier.

Many of our extended qualifiers completely change the ABI of the type they qualify, and they can change the basic semantic properties of types they're nested within.  I don't see why we'd draw a line here about what counts as a qualifier and what doesn't.  ObjC ARC happens to implement `__weak` references without using extra inline storage, but it would certainly be a reasonable ABI choice to make them larger than just a pointer — Swift does with its native weak references, for example.  That ABI choice wouldn't make `__weak` suddenly not a qualifier.

> I saw some talk in WG14 of separating _Atomic(T) and _Atomic T so that _Atomic T would be a qualifier that doesn't affect size or alignment, only what code is generated to access the value, and _Atomic(T) would be a distinct type with potentially a different representation in order to support lock-free atomic access. Did that go anywhere? (I'd assume not, it seems to be at least a decade too late for such an idea.)

That seems like a terrible idea.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125919/new/

https://reviews.llvm.org/D125919