This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-11-11

1181. What is a “built-in type?”

[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):

1. Change 6.7.2 [intro.object] paragraph 7 as follows:

[Note: C++ provides a variety of built-in fundamental types and several ways of composing new types from existing types (6.8 [basic.types]). —end note]

2. Change 5.4 [lex.pptoken] as follows:

[Example: The program fragment x+++++y is parsed as x ++ ++ + y, which, if x and y are of built-in have integral types, violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a correct expression. —end example]

3. Change 17.3.5.2 [numeric.limits.members] paragraph 58 as follows:

True if the set of values representable by the type is finite.²²⁰ [Note: All built-in fundamental types (6.8.2 [basic.fundamental]) are bounded. This member would be false for arbitrary precision types. —end note]

4. Change 25.3.1 [iterator.requirements.general] paragraph 1 as follows:

...All input iterators i support the expression *i, resulting in a value of some class, enumeration, or built-in object type T, called the value type of the iterator...

5. Change 25.3.5.3 [input.iterators] paragraph 1 as follows:

A class or a built-in pointer type X satisfies the requirements of an input iterator for the value type T if X satisfies the Iterator (25.3.5.2 [iterator.iterators]) and EqualityComparable (Table 33) requirements and the expressions in Table 107 are valid and have the indicated semantics.

6. Change 25.3.5.4 [output.iterators] paragraph 1 as follows:

A class or a built-in pointer type X satisfies the requirements of an output iterator if X if X satisfies the Iterator requirements (25.3.5.2 [iterator.iterators]) and the expressions in Table 108 are valid and have the indicated semantics.

7. Change 25.3.5.5 [forward.iterators] paragraph 1 as follows:

A class or a built-in pointer type X satisfies the requirements of a forward iterator if...

8. Change 25.3.5.6 [bidirectional.iterators] paragraph 1 as follows:

A class or a built-in pointer 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.

9. Change 25.3.5.7 [random.access.iterators] paragraph 1 as follows:

A class or a built-in pointer 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.

10. Change C.7.3 [diff.basic] section 3.1 as follows:

Rationale: This avoids having different initialization rules for built-in fundamental types and user-defined types.

11. 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 of built-in fundamental types...

12. 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.)