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

Fri Jun 3 10:54:19 PDT 2022

aaron.ballman added a comment.

In D125919#3556319 <https://reviews.llvm.org/D125919#3556319>, @rjmccall wrote:

> Are you now arguing that C was wrong to drop qualifiers in return types and so we shouldn't implement that rule, or...?  Because your argument is much broader than just `_Atomic`.

That's my current thinking, but I'm still considering the ramifications. But it seems to me that dropping qualifications on lvalue to rvalue conversion, which happens for function returns anyways, is sufficient to have resolved DR423.

I'm quite peeved that:

  int func(void);
  const int func(void);

is valid C but invalid C++; that seems gratuitously incompatible in light of the lvalue to rvalue behavior.

> I don't understand the analogy you're making to `_Complex` at all.  Values of type `_Complex T` are fundamentally different from values of type `T`, because inherently they have to store two of them.  `_Imaginary` (which Clang does not implement) is more or less just a semantic recast of `T`, but that recast is still critically important to the nature of the type, and in no way does it act like a qualifier.  Meanwhile, `_Atomic` is only meaningful at the top level on l-values, exactly like a qualifier, and you can assign non-atomic r-values into an atomic l-value and read them back out again, just like a qualifier.

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.

> Now, the standard has chosen not to talk about `_Atomic` as a qualifier, I assume because there's a fair number of rules in the standard that assume that qualifiers can be freely added to pointers and don't change layout and so on, none of which apply to `_Atomic`.  But those rules also don't apply to a large number of other extended qualifiers, like address spaces and the ARC ownership qualifiers and `__ptrauth`.  The committee should probably just come to terms with the fact that it's the relatively easy-come-easy-go nature of the CVR qualifiers which is the special case.  I've thought for awhile that Clang should really be representing `_Atomic` as a qualifier instead of having to treat `AtomicType` as a special case in a million places.

I'm not certain if we can get away with that. IIRC, Microsoft uses embedded locks on Windows in some circumstances. However, cl doesn't support `_Atomic` and so maybe we can get away with it on the assumption we have no other targets where the size/alignment would be different for an atomic type vs a non-atomic type?

> I see absolutely no reason why anybody should ever want to declare a function as `_Atomic(int) func(void);`, and if the C and C++ committees decide to break people who aren't just doing it but are doing it inconsistently, they're doing the world a service.

I tend to agree -- top-level qualification on a return type is deeply strange in C. However, it's something observable in C++ due to template metaprogramming and type traits, so I don't see C++ changing the type system to disallow it as C as done. Given that C++ is unlikely to move the needle, it seems more plausible to move it in C where top-level qualification of a return type is really hard to observe except through redeclaration errors.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125919