This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-12-19
[Voted into the WP at the March, 2011 meeting.]
The current draft uses the term “built-in type” several times, but it is not defined anywhere. The Index appears to make it synonymous with “fundamental type,” but the implication of 7.3 [conv] paragraph 1 is that compound types like pointers should also be considered as “built-in.”
Proposed resolution (January, 2011):
Change 6.7.2 [intro.object] paragraph 7 as follows:
[Note: C++ provides a variety ofbuilt-infundamental types and several ways of composing new types from existing types (6.8 [basic.types]). —end note]
Change 5.5 [lex.pptoken] as follows:
[Example: The program fragment x+++++y is parsed as x ++ ++ + y, which, if x and yare of built-inhave integral types, violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a correct expression. —end example]
Change 17.3.5.2 [numeric.limits.members] paragraph 58 as follows:
True if the set of values representable by the type is finite.220 [Note: Allbuilt-infundamental types (6.8.2 [basic.fundamental]) are bounded. This member would be false for arbitrary precision types. —end note]
Change 24.3.1 [iterator.requirements.general] paragraph 1 as follows:
...All input iterators i support the expression *i, resulting in a value of someclass, enumeration, or built-inobject type T, called the value type of the iterator...
Change 24.3.5.3 [input.iterators] paragraph 1 as follows:
A class or abuilt-inpointer type X satisfies the requirements of an input iterator for the value type T if X satisfies the Iterator (24.3.5.2 [iterator.iterators]) and EqualityComparable (Table 33) requirements and the expressions in Table 107 are valid and have the indicated semantics.
Change 24.3.5.4 [output.iterators] paragraph 1 as follows:
A class or abuilt-inpointer type X satisfies the requirements of an output iteratorif Xif X satisfies the Iterator requirements (24.3.5.2 [iterator.iterators]) and the expressions in Table 108 are valid and have the indicated semantics.
Change 24.3.5.5 [forward.iterators] paragraph 1 as follows:
A class or abuilt-inpointer type X satisfies the requirements of a forward iterator if...
Change 24.3.5.6 [bidirectional.iterators] paragraph 1 as follows:
A class or abuilt-inpointer type X satisfies the requirements of a bidirectional iterator if, in addition to satisfying the requirements for forward iterators, the following expressions are valid as shown in Table 110.
Change 24.3.5.7 [random.access.iterators] paragraph 1 as follows:
A class or abuilt-inpointer type X satisfies the requirements of a random access iterator if, in addition to satisfying the requirements for bidirectional iterators, the following expressions are valid as shown in Table 111.
Change C.7.3 [diff.basic] section 3.1 as follows:
Rationale: This avoids having different initialization rules forbuilt-infundamental types and user-defined types.
Change C.7.7 [diff.class] section 9.1 as follows:
...This new name space definition provides important notational conveniences to C++ programmers and helps making the use of the user-defined types as similar as possible to the use ofbuilt-infundamental types...
Delete the index entry, “built-in type; see fundamental type
.”(Note: This resolution assumes that the resolution for issue 572 has been applied, removing “built-in type” from 7.3 [conv] paragraph 1.)