[PATCH] D125919: Drop qualifiers from return types in C (DR423)
John McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Jun 3 10:22:20 PDT 2022
rjmccall added a comment.
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`.
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`. `_Imaginary` (which Clang does not implement) is more like a semantic recast of `T`, but that recast is critically important, 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.
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`, and the committee should probably just come to terms with the fact that it's the relative easy-come-easy-go nature of the CVR qualifiers which is the special case.
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.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D125919/new/
https://reviews.llvm.org/D125919
More information about the cfe-commits
mailing list