Joseph Myers <[email protected]> writes: > I suspect it *should* be a qualifier (that's not an access qualifier) > in the standard - that making it such would mean fewer special cases > referring to "atomic, qualified or unqualified" and similar than you > get at present with it not being a qualifier but having qualifier-like > properties regarding not being possible for rvalues. > > In implementation terms, not being a qualfier would mean that > everything that checks for a particular kind of type > (e.g. POINTER_TYPE) would suddenly be more complicated because of > needing to check for being an atomic type wrapper round that kind of > type as well. (We do already have some awkward cases like that. For > example, enumerations with fixed underlying type bool need checking > for everywhere concerned with the special semantics of conversion to > bool - but if atomic types were no longer represented as qualifiers, > suddenly you get the extra complication that first you need to remove > atomic, then move from enumeration to underlying type, and only then > check for a boolean type. The standard text has a similar issue of > not having any convenient term for "integer type that behaves like > bool" - or for that matter for signed-behavior and unsigned-behavior > types.)
That's true; it would convolute the implementation somewhat. Then, maybe, making 'includes_p' (the predicate that was checking whether QS1 includes all qualifiers of QS2) actually be called usable_as_p or such, and having it reject TYPE_QUAL_ATOMIC differences makes sense? (I'd prefer a better name, because 'usable as' sounds like it implies a NOP_EXPR suffices for conversion, but that may not be true due to address spaces, but I'm coming up blank) Given this special nature of TYPE_QUAL_ATOMIC, I'm not sure in which cases it would be applicable to have a "pure" includes predicate. What do you think? -- Arsen Arsenović
signature.asc
Description: PGP signature
