Proposed resolution:

I propose to use the terms "signed integer type" and "unsigned integer type" in place of "signed integral type" and "unsigned integral type" to eliminate such ambiguities.

The proposed change makes it absolutely clear that the difference between two pointers cannot be char or wchar_t, but could be any of the signed integer types. [expr.add] paragraph 6...

1. When two pointers to elements of the same array object are subtracted, the result is the difference of the subscripts of the two array elements. The type of the result is an implementation-defined signed integral typesigned integer type; this type shall be the same type that is defined as std::ptrdiff_t in the <cstdint> header (18.1)...

The proposed change makes it clear that X::size_type and X::difference_type cannot be char or wchar_t, but could be one of the signed or unsigned integer types as appropriate. [allocator.requirements] table 40...

Table 40: Allocator requirements

expression	return type	assertion/note/pre/post-condition
X::size_type	unsigned integral type unsigned integer type	a type that can represent the size of the largest object in the allocation model.
X::difference_type	signed integral type signed integer type	a type that can represent the difference between any two pointers in the allocation model.

The proposed change makes it clear that make_signed<T>::type must be one of the signed integer types as defined in 3.9.1. Ditto for make_unsigned<T>type and unsigned integer types. [meta.trans.sign] table 48...

Table 48: Sign modifications

Template	Comments
template <class T> struct make_signed;	If T names a (possibly cv-qualified) signed integral typesigned integer type (3.9.1) then the member typedef type shall name the type T; otherwise, if T names a (possibly cv-qualified) unsigned integral typeunsigned integer type then type shall name the corresponding signed integral typesigned integer type, with the same cv-qualifiers as T; otherwise, type shall name the signed integral typesigned integer type with the smallest rank (4.13) for which sizeof(T) == sizeof(type), with the same cv-qualifiers as T. Requires: T shall be a (possibly cv-qualified) integral type or enumeration but not a bool type.
template <class T> struct make_unsigned;	If T names a (possibly cv-qualified) unsigned integral typeunsigned integer type (3.9.1) then the member typedef type shall name the type T; otherwise, if T names a (possibly cv-qualified) signed integral typesigned integer type then type shall name the corresponding unsigned integral typeunsigned integer type, with the same cv-qualifiers as T; otherwise, type shall name the unsigned integral typeunsigned integer type with the smallest rank (4.13) for which sizeof(T) == sizeof(type), with the same cv-qualifiers as T. Requires: T shall be a (possibly cv-qualified) integral type or enumeration but not a bool type.

Note: I believe that the basefield values should probably be prefixed with ios_base:: as they are in [facet.num.put.virtuals] The listed virtuals are all overloaded on signed and unsigned integer types, the new wording just maintains consistency. [facet.num.get.virtuals] table 78...

Table 78: Integer Conversions

State	stdio equivalent
basefield == oct	%o
basefield == hex	%X
basefield == 0	%i
signed integral typesigned integer type	%d
unsigned integral typeunsigned integer type	%u

Rationale is same as above. [facet.num.put.virtuals] table 80...

Table 80: Integer Conversions

State	stdio equivalent
basefield == ios_base::oct	%o
(basefield == ios_base::hex) && !uppercase	%x
(basefield == ios_base::hex)	%X
basefield == 0	%i
for a signed integral typesigned integer type	%d
for a unsigned integral typeunsigned integer type	%u

[container.requirements] table 80...

Table 89: Container requirements

expression	return type	operational semantics	assertion/note/pre/post-condition	complexity
X::difference_type	signed integral typesigned integer type		is identical to the difference type of X::iterator and X::const_iterator	compile time
X::size_type	unsigned integral typeunsigned integer type		size_type can represent any non-negative value of difference_type	compile time

[iterator.concepts] paragraph 1...

Iterators are a generalization of pointers that allow a C++ program to work with different data structures (containers) in a uniform manner. To be able to construct template algorithms that work correctly and efficiently on different types of data structures, the library formalizes not just the interfaces but also the semantics and complexity assumptions of iterators. All input iterators i support the expression *i, resulting in a value of some class, enumeration, or built-in type T, called the value type of the iterator. All output iterators support the expression *i = o where o is a value of some type that is in the set of types that are writable to the particular iterator type of i. All iterators i for which the expression (*i).m is well-defined, support the expression i->m with the same semantics as (*i).m. For every iterator type X for which equality is defined, there is a corresponding signed integral type signed integer type called the difference type of the iterator.

I'm a little unsure of this change. Previously this paragraph would allow instantiations of linear_congruential_engine on char, wchar_t, bool, and other types. The new wording prohibits this. [rand.eng.lcong] paragraph 2...

The template parameter UIntType shall denote an unsigned integral typeunsigned integer type large enough to store values as large as m - 1. If the template parameter m is 0, the modulus m used throughout this section 26.4.3.1 is numeric_limits<result_type>::max() plus 1. [Note: The result need not be representable as a value of type result_type. --end note] Otherwise, the following relations shall hold: a < m and c < m.

Same rationale as the previous change. [rand.adapt.xor] paragraph 6...

Both Engine1::result_type and Engine2::result_type shall denote (possibly different) unsigned integral typesunsigned integer types. The member result_type shall denote either the type Engine1::result_type or the type Engine2::result_type, whichever provides the most storage according to clause 3.9.1.

[rand.util.seedseq] paragraph 7...

Requires:RandomAccessIterator shall meet the requirements of a random access iterator (24.1.5) such that iterator_traits<RandomAccessIterator>::value_type shall denote an unsigned integral typeunsigned integer type capable of accomodating 32-bit quantities.

By making this change, integral types that happen to have a signed representation, but are not signed integer types, would no longer be required to use a two's complement representation. This may go against the original intent, and should be reviewed. [atomics.types.operations] paragraph 24...

Remark: For signed integral typessigned integer types, arithmetic is defined using two's complement representation. There are no undefined results. For address types, the result may be an undefined address, but the operations otherwise have no undefined behavior.

[ Post Summit Daniel adds: ]

The proposed resolution needs to be "conceptualized". Currently we have in [concept.support] only concept IntegralType for all "integral types", thus indeed the current Container concept and Iterator concepts are sufficiently satisfied with "integral types". If the changes are applied, we might ask core for concept BilateralIntegerType and add proper restrictions to the library concepts.

[ San Francisco: ]

Plum, Sebor to review.

Neither the term "signed integral type" nor the term "unsigned integral type" is defined in the core language section of the standard, therefore the library section should avoid its use. The terms signed integer type and unsigned integer type are indeed defined (in [basic.fundamental]), thus the usages should be replaced accordingly.

Note that the key issue here is that "signed" + "integral type" != "signed integral type". The types bool, char, char16_t, char32_t and wchar_t are all listed as integral types, but are neither of signed integer type or unsigned integer type. According to [basic.types] p7, a synonym for integral type is integer type. Given this, one may choose to assume that an integral type that can represent values less than zero is a signed integral type. Unfortunately this can cause ambiguities. As an example, if T is unsigned char, the expression make_signed<T>::type, is supposed to name a signed integral type. There are potentially two types that satisfy this requirement, namely signed char and char (assuming CHAR_MIN < 0).