John Maddock wrote:
If anyone would like to comment on the other issues g.peterhoff has raised, second opinions are always most welcome:
https://github.com/boostorg/type_traits/issues/185 https://github.com/boostorg/type_traits/issues/186 https://github.com/boostorg/type_traits/issues/187 https://github.com/boostorg/type_traits/issues/188 https://github.com/boostorg/type_traits/issues/189 https://github.com/boostorg/type_traits/issues/190 https://github.com/boostorg/type_traits/issues/191 https://github.com/boostorg/type_traits/issues/192 https://github.com/boostorg/type_traits/issues/193 https://github.com/boostorg/type_traits/issues/194
Since integral types are actually a compound category in the standard, "The character types, bool, the signed and unsigned integer types, and cv-qualified versions ([basic.type.qualifier]) thereof, are collectively termed integral types." I think there is justification for providing the separate categories for signed integer (https://eel.is/c++draft/basic.fundamental#1), unsigned integer (https://eel.is/c++draft/basic.fundamental#2), character (https://eel.is/c++draft/basic.fundamental#11) and, for completeness, bool. There exist uses for each of the above categories. E.g. countl_zero requires an unsigned integer type; Endian requires "an integral type that is not bool"; and functions that want to take C strings need to be constrained on a character type.