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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
