On Tue, 27 Jun 2017, Martin Sebor wrote: > > Another thing, with the current patch, __typeof_noqual__(const int) > > would still produce "const int". With the __atomic_load_n proposal > > it'd return "int". I don't know what we want to do for typenames, > > but __typeof__(_Atomic int) produces "atomic int". > > I missed that. That seems surprising. I would expect the trait > to evaluate to the same type regardless of the argument (type or > expression). Why does it only strip qualifiers from expressions > and not also from types?
The type stripping from atomic expressions is basically what's necessary for some stdatomic.h macros to work, while minimizing the risk to existing code. Of course when adding _Atomic, anything whatever could have been done with atomic types without risk to existing code, but I suppose there is a case for thinking of typeof (typename) as being purely like parentheses - not modifying the type at all. I'd expect __typeof_noqual to remove qualifiers from both expressions and type names. There's the usual question of what should be done with arrays of qualified types (where C does not consider such an array type to be qualified, but C++ considers it to have the same qualifiers as the element type). There's also the matter of qualifiers used internally by GCC to represent const and noreturn functions. > Unless __typeof__ (p) q = p; declares a restrict-qualified q when > p is a restrict-qualified pointer I don't think __remove_restrict > is needed. Restrict doesn't qualify a type but rather a pointer > object it applies to so I would find the effect above unexpected restrict acts as a type qualifier in C terms, the type being "restrict-qualifiers pointer to ...". I'd expect it to work just like const and volatile in __typeof and __typeof_noqual. -- Joseph S. Myers jos...@codesourcery.com