N3362=12-0052
revision of: N3324=12-0014
Jens Maurer
2012-02-10

Terminology: "indirection" versus "dereference" (revision 2)

This paper addresses core issue 342 and implements a consistent terminology for "indirection through a pointer" throughout the core language section of the standard. As decided in Bloomington, the term "dereference" would be replaced by "indirection". This paper reflects the additional comments made during review at the Kona meeting. Due to the volume of the changes, they are presented as a separate paper as opposed to integrating them into the core issues list.

Here is the list of places that already uses "indirection": Change in 3.7.4.1 basic.stc.dynamic.allocation paragraph 2:
... The effect of dereferencing indirecting through a pointer returned as a request for zero size is undefined. [ Footnote: ... ]
Change in 3.7.4.3 basic.stc.dynamic.safety paragraph 2:
Change in 3.8 basic.life paragraph 5:
... Indirection through such Such a pointer may be dereferenced is permitted but the resulting lvalue may only be used in limited ways, as described below. The program has undefined behavior if:
Change in 4.11 conv.mem paragraph 2:
... Since the result has type "pointer to member of D of type cv T", it can be dereferenced indirection through it with a D object is valid. The result is the same as if indirecting through the pointer to member of B were dereferenced with the B subobject of D. The null member pointer value is converted to the null member pointer value of the destination type. [ Footnote: ... ]
Change in 5.2.9 expr.static.cast paragraph 12:
... [ Note: although class B need not contain the original member, the dynamic type of the object on with which indirection through the pointer to member is performed dereferenced must contain the original member; see 5.5 expr.mptr.oper. -- end note ]
Change in 5.3.1 expr.unary.op paragraph 1:
... [ Note: indirection through a pointer to an incomplete type (other than cv void) is valid can be dereferenced. ... ]
Change in 5.10 expr.eq paragraph 2:
... Otherwise they compare equal if and only if they would refer to the same member of the same most derived object (1.8 intro.object) or the same subobject if they were dereferenced indirection with a hypothetical object of the associated class type were performed. [ Example: ... ]
Change in 7.5 dcl.link paragraph 8:
[ Note: Because the language linkage is part of a function type, when indirecting through a pointer to C function (for example) is dereferenced, the function to which it the resulting lvalue refers is considered a C function. -- end note ]
Change in 8.3.2 dcl.ref paragraph 5:
... [ Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the "object" obtained by dereferencing indirection through a null pointer, which causes undefined behavior. As described in 9.6 class.bit, a reference cannot be bound directly to a bit-field. ]
Drafting note: The term "dereferenceable" is defined for iterators in 24.2.1p5. I see no need to eradicate that term. Therefore, 17.6.3.2 swappable.requirements p5, 23.2.3 sequence.reqmts p3, 23.2.4 associative.reqmts p8 and many more are unchanged.

Change in 17.6.3.5 allocator.requirements table 27:

a dereferenceable pointer of type C* through which indirection is valid
Change in 20.6.3.2 pointer.traits.functions:
Returns: The first member function returns a dereferenceable pointer to r obtained by calling Ptr::pointer_to(r) through which indirection is valid; an instantiation of this function is ill-formed if Ptr does not have a matching pointer_to static member function. The second member function returns std::addressof(r).
Change in 20.6.4 util.dynamic.safety paragraph 10:
... Hence indirection through a pointer pointers located there may not be dereferenced is undefined if the object they point it points to was created by global operator new and not previously declared reachable. [ Note: ... ]
Change in 20.6.12 specialized.algorithms paragraph 1:
... In all of the following algorithms, the formal template parameter ForwardIterator is required to satisfy the requirements of a forward iterator (24.2.5 forward.iterators), and is required to have the property that no exceptions are thrown from increment, assignment, comparison, or dereference of indirection through valid iterators. ...
Change in 22.4.5.1.2 locale.time.get.virtuals paragraph 11:
Requires: t shall be dereferenceable point to an object.
Change in 23.4.4.2 map.cons paragraph 3:
Requires: If the iterator's dereference indirection operator returns an lvalue or a const rvalue pair<key_type, mapped_type>, then both key_type and mapped_type shall be CopyConstructible.
Change in 23.4.5.2 multimap.cons paragraph 3:
Requires: If the iterator's dereference indirection operator returns an lvalue or a const rvalue pair<key_type, mapped_type>, then both key_type and mapped_type shall be CopyConstructible.
Change in 23.4.6.2 set.cons paragraph 4:
Requires If the iterator's dereference indirection operator returns an lvalue or a non-const rvalue, then Key shall be CopyConstructible.
Change in 23.4.7.2 multiset.cons paragraph 3:
Requires If the iterator's dereference indirection operator returns an lvalue or a non-const rvalue, then Key shall be CopyConstructible.
Change in 24.5.3 move.iterators paragraph 1:
Class template move_iterator is an iterator adaptor with the same behavior as the underlying iterator except that its dereference indirection operator implicitly converts the value returned by the underlying iterator's dereference indirection operator to an rvalue reference. ....
Change the title of 28.12.1.3 re.regiter.deref
regex_iterator dereference indirection
Change the title of 28.12.2.3 re.tokiter.deref
regex_token_iterator dereference indirection