On Mon, 8 Dec 2025 at 10:04, Jonathan Wakely <[email protected]> wrote: > > We have __is_signed_integer and __is_unsigned_integer traits which > should have been updated by r16-2190-g4faa42ac0dee2c when making > __int128 an extended integer type (for PR libstdc++/96710). Currently > they check whether the type is a signed integer type or an unsigned > integer type, or a cv-qualified version of one of those. This doesn't > match the standard's definition, which does not include cv-qualified > types. This change ensures that signed __int128 and unsigned __int128 > are included in those traits in strict -std modes, and it removes the > use of remove_cv_t so that they are not true for cv-qualified types. > This makes the traits match the meaning of "signed integer type" and > "unsigned integer type" in the standard ([basic.fundamental]). > > We also have an __is_standard_integer trait, which is true if either > __is_signed_integer or __is_unsigned_integer is true, but that's also > not a match for the definition in the standard. The definitions of > "signed integer type" and "unsigned integer type" include both standard > and extended integer types, so only saying "standard" in the trait name > is misleading (even before this change, because in non-strict -std modes > the __GLIBCXX_TYPE_INT_N_0 .. __GLIBCXX_TYPE_INT_N_3 types were always > included in the trait, and they aren't standard integer types). > > This change renames __is_standard_integer to the more accurate > __is_signed_or_unsigned_integer_type. Because the set of signed and > unsigned integer types is the same as the set of standard and extended > integer types, the trait could instead have been renamed to > __is_standard_or_extended_integer_type. I think it's clearer and more > self-explanatory to avoid "standard and extended" and name it for the > signed and unsigned integer types. > > N.N. we don't want to call it just __is_integer_type because the integer
Oops, that was meant to say N.B. I'll fix that before pushing anything.
