CWG Issue 1181 (original) (raw)

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

2025-11-05

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

Section: 6.9 [basic.types]Status: C++11Submitter: Barry HedquistDate: 2010-08-26

[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.8.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.9 [basic.types]). —_end note_]

1. Change 5.5 [lex.pptoken] as follows:

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

1. 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:_ All built-in fundamental types (6.9.2 [basic.fundamental])are bounded. This member would be false for arbitrary precision types. —_end note_]

1. Change 24.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...

1. Change 24.3.5.3 [input.iterators] paragraph 1 as follows:

A class or a built-in pointer type Xsatisfies the requirements of an input iterator for the value typeT 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.

1. Change 24.3.5.4 [output.iterators] paragraph 1 as follows:

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

1. Change 24.3.5.5 [forward.iterators] paragraph 1 as follows:

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

1. Change 24.3.5.6 [bidirectional.iterators] paragraph 1 as follows:

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

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

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

1. 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.

1. 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-in fundamental types...

1. Delete the index entry, “built-in type; see fundamental type
   .”

(Note: This resolution assumes that the resolution forissue 572 has been applied, removing “built-in type” from 7.3 [conv] paragraph 1.)