[class.member.lookup] - C++20 → C++23

Files changed (1) hide show

tmp/tmppcjfwkuu/{from.md → to.md} +77 -102

tmp/tmppcjfwkuu/{from.md → to.md} RENAMED Viewed

@@ -1,69 +1,60 @@
-## Member name lookup <a id="class.member.lookup">[[class.member.lookup]]</a>
-Member name lookup determines the meaning of a name (*id-expression*) in
-a class scope [[basic.scope.class]]. Name lookup can result in an
-ambiguity, in which case the program is ill-formed. For an
-*unqualified-id*, name lookup begins in the class scope of `this`; for a
-*qualified-id*, name lookup begins in the scope of the
-*nested-name-specifier*. Name lookup takes place before access control (
-[[basic.lookup]], [[class.access]]).
-The following steps define the result of name lookup for a member name
-`f` in a class scope `C`.
-The *lookup set* for `f` in `C`, called S(f,C), consists of two
-component sets: the *declaration set*, a set of members named `f`; and
-the *subobject set*, a set of subobjects where declarations of these
-members (possibly including *using-declaration*s) were found. In the
-declaration set, *using-declaration*s are replaced by the set of
-designated members that are not hidden or overridden by members of the
-derived class [[namespace.udecl]], and type declarations (including
-injected-class-names) are replaced by the types they designate. S(f,C)
-is calculated as follows:
-If `C` contains a declaration of the name `f`, the declaration set
-contains every declaration of `f` declared in `C` that satisfies the
-requirements of the language construct in which the lookup occurs.
-[*Note 1*: Looking up a name in an *elaborated-type-specifier*
-[[basic.lookup.elab]] or *base-specifier* [[class.derived]], for
-instance, ignores all non-type declarations, while looking up a name in
-a *nested-name-specifier* [[basic.lookup.qual]] ignores function,
-variable, and enumerator declarations. As another example, looking up a
-name in a *using-declaration* [[namespace.udecl]] includes the
-declaration of a class or enumeration that would ordinarily be hidden by
-another declaration of that name in the same scope. — *end note*]
-If the resulting declaration set is not empty, the subobject set
-contains `C` itself, and calculation is complete.
-Otherwise (i.e., `C` does not contain a declaration of `f` or the
-resulting declaration set is empty), S(f,C) is initially empty. If `C`
-has base classes, calculate the lookup set for `f` in each direct base
-class subobject Bᵢ, and merge each such lookup set S(f,Bᵢ) in turn into
-S(f,C).
-The following steps define the result of merging lookup set S(f,Bᵢ) into
-the intermediate S(f,C):
-- If each of the subobject members of S(f,Bᵢ) is a base class subobject
-  of at least one of the subobject members of S(f,C), or if S(f,Bᵢ) is
-  empty, S(f,C) is unchanged and the merge is complete. Conversely, if
-  each of the subobject members of S(f,C) is a base class subobject of
-  at least one of the subobject members of S(f,Bᵢ), or if S(f,C) is
-  empty, the new S(f,C) is a copy of S(f,Bᵢ).
-- Otherwise, if the declaration sets of S(f,Bᵢ) and S(f,C) differ, the
-  merge is ambiguous: the new S(f,C) is a lookup set with an invalid
   declaration set and the union of the subobject sets. In subsequent
   merges, an invalid declaration set is considered different from any
   other.
-- Otherwise, the new S(f,C) is a lookup set with the shared set of
   declarations and the union of the subobject sets.
-The result of name lookup for `f` in `C` is the declaration set of
-S(f,C). If it is an invalid set, the program is ill-formed.
 [*Example 1*:
 ``` cpp
 struct A { int x; };                    // S(x,A) = { { A::x }, { A } }
@@ -76,50 +67,34 @@ int main() {
   F f;
   f.x = 0;                              // OK, lookup finds E::x
 }
 ```
-S(x,F) is unambiguous because the `A` and `B` base class subobjects of
-`D` are also base class subobjects of `E`, so S(x,D) is discarded in the
-first merge step.
 — *end example*]
-If the name of an overloaded function is unambiguously found, overload
-resolution [[over.match]] also takes place before access control.
-Ambiguities can often be resolved by qualifying a name with its class
-name.
-[*Example 2*:
-``` cpp
-struct A {
-  int f();
-};
-```
-``` cpp
-struct B {
-  int f();
-};
-```
-``` cpp
-struct C : A, B {
-  int f() { return A::f() + B::f(); }
-};
-```
-— *end example*]
-[*Note 2*: A static member, a nested type or an enumerator defined in a
 base class `T` can unambiguously be found even if an object has more
 than one base class subobject of type `T`. Two base class subobjects
 share the non-static member subobjects of their common virtual base
 classes. — *end note*]
-[*Example 3*:
 ``` cpp
 struct V {
   int v;
 };
@@ -131,27 +106,27 @@ struct A {
 struct B : A, virtual V { };
 struct C : A, virtual V { };
 struct D : B, C { };
 void f(D* pd) {
-  pd->v++;          // OK: only one v (virtual)
-  pd->s++;          // OK: only one s (static)
-  int i = pd->e;    // OK: only one e (enumerator)
   pd->a++;          // error: ambiguous: two a{s} in D
 }
 ```
 — *end example*]
-[*Note 3*:  When virtual base classes are used, a hidden declaration
 can be reached along a path through the subobject lattice that does not
 pass through the hiding declaration. This is not an ambiguity. The
 identical use with non-virtual base classes is an ambiguity; in that
 case there is no unique instance of the name that hides all the
 others. — *end note*]
-[*Example 4*:
 ``` cpp
 struct V { int f();  int x; };
 struct W { int g();  int y; };
 struct B : virtual V, W {
@@ -172,12 +147,12 @@ As illustrated in Figure [[fig:class.lookup]], the names declared in
 the names declared in the right-hand instance of `W` are not hidden at
 all.
 ``` cpp
 void D::glorp() {
-  x++;              // OK: B::x hides V::x
-  f();              // OK: B::f() hides V::f()
   y++;              // error: B::y and C's W::y
   g();              // error: B::g() and C's W::g()
 }
 ```
@@ -186,11 +161,11 @@ void D::glorp() {
 An explicit or implicit conversion from a pointer to or an expression
 designating an object of a derived class to a pointer or reference to
 one of its base classes shall unambiguously refer to a unique object
 representing the base class.
-[*Example 5*:
 ``` cpp
 struct V { };
 struct A { };
 struct B : A, virtual V { };
@@ -199,21 +174,21 @@ struct D : B, C { };
 void g() {
   D d;
   B* pb = &d;
   A* pa = &d;       // error: ambiguous: C's A or B's A?
-  V* pv = &d;       // OK: only one V subobject
 }
 ```
 — *end example*]
-[*Note 4*: Even if the result of name lookup is unambiguous, use of a
-name found in multiple subobjects might still be ambiguous (
-[[conv.mem]], [[expr.ref]], [[class.access.base]]). — *end note*]
-[*Example 6*:
 ``` cpp
 struct B1 {
   void f();
   static void f(int);

+### Member name lookup <a id="class.member.lookup">[[class.member.lookup]]</a>
+A *search* in a scope X for a name M from a program point P is a single
+search in X for M from P unless X is the scope of a class or class
+template T, in which case the following steps define the result of the
+search.
+[*Note 1*: The result differs only if M is a *conversion-function-id*
+or if the single search would find nothing. — *end note*]
+The *lookup set* for a name N in a class or class template C, called
+S(N,C), consists of two component sets: the *declaration set*, a set of
+members named N; and the *subobject set*, a set of subobjects where
+declarations of these members were found (possibly via
+*using-declaration*s). In the declaration set, type declarations
+(including injected-class-names) are replaced by the types they
+designate. S(N,C) is calculated as follows:
+The declaration set is the result of a single search in the scope of C
+for N from immediately after the *class-specifier* of C if P is in a
+complete-class context of C or from P otherwise. If the resulting
+declaration set is not empty, the subobject set contains C itself, and
+calculation is complete.
+Otherwise (i.e., C does not contain a declaration of N or the resulting
+declaration set is empty), S(N,C) is initially empty. Calculate the
+lookup set for N in each direct non-dependent [[temp.dep.type]] base
+class subobject Bᵢ, and merge each such lookup set S(N,Bᵢ) in turn into
+S(N,C).
+[*Note 2*: If C is incomplete, only base classes whose *base-specifier*
+appears before P are considered. If C is an instantiated class, its base
+classes are not dependent. — *end note*]
+The following steps define the result of merging lookup set S(N,Bᵢ) into
+the intermediate S(N,C):
+- If each of the subobject members of S(N,Bᵢ) is a base class subobject
+  of at least one of the subobject members of S(N,C), or if S(N,Bᵢ) is
+  empty, S(N,C) is unchanged and the merge is complete. Conversely, if
+  each of the subobject members of S(N,C) is a base class subobject of
+  at least one of the subobject members of S(N,Bᵢ), or if S(N,C) is
+  empty, the new S(N,C) is a copy of S(N,Bᵢ).
+- Otherwise, if the declaration sets of S(N,Bᵢ) and S(N,C) differ, the
+  merge is ambiguous: the new S(N,C) is a lookup set with an invalid
   declaration set and the union of the subobject sets. In subsequent
   merges, an invalid declaration set is considered different from any
   other.
+- Otherwise, the new S(N,C) is a lookup set with the shared set of
   declarations and the union of the subobject sets.
+The result of the search is the declaration set of S(M,T). If it is an
+invalid set, the program is ill-formed. If it differs from the result of
+a search in T for M in a complete-class context [[class.mem]] of T, the
+program is ill-formed, no diagnostic required.
 [*Example 1*:
 ``` cpp
 struct A { int x; };                    // S(x,A) = { { A::x }, { A } }
   F f;
   f.x = 0;                              // OK, lookup finds E::x
 }
 ```
+S(`x`,`F`) is unambiguous because the `A` and `B` base class subobjects
+of `D` are also base class subobjects of `E`, so S(`x`,`D`) is discarded
+in the first merge step.
 — *end example*]
+If M is a non-dependent *conversion-function-id*, conversion function
+templates that are members of T are considered. For each such template
+F, the lookup set S(t,T) is constructed, considering a function template
+declaration to have the name t only if it corresponds to a declaration
+of F [[basic.scope.scope]]. The members of the declaration set of each
+such lookup set, which shall not be an invalid set, are included in the
+result.
+[*Note 3*: Overload resolution will discard those that cannot convert
+to the type specified by M [[temp.over]]. — *end note*]
+[*Note 4*: A static member, a nested type or an enumerator defined in a
 base class `T` can unambiguously be found even if an object has more
 than one base class subobject of type `T`. Two base class subobjects
 share the non-static member subobjects of their common virtual base
 classes. — *end note*]
+[*Example 2*:
 ``` cpp
 struct V {
   int v;
 };
 struct B : A, virtual V { };
 struct C : A, virtual V { };
 struct D : B, C { };
 void f(D* pd) {
+  pd->v++;          // OK, only one v (virtual)
+  pd->s++;          // OK, only one s (static)
+  int i = pd->e;    // OK, only one e (enumerator)
   pd->a++;          // error: ambiguous: two a{s} in D
 }
 ```
 — *end example*]
+[*Note 5*:  When virtual base classes are used, a hidden declaration
 can be reached along a path through the subobject lattice that does not
 pass through the hiding declaration. This is not an ambiguity. The
 identical use with non-virtual base classes is an ambiguity; in that
 case there is no unique instance of the name that hides all the
 others. — *end note*]
+[*Example 3*:
 ``` cpp
 struct V { int f();  int x; };
 struct W { int g();  int y; };
 struct B : virtual V, W {
 the names declared in the right-hand instance of `W` are not hidden at
 all.
 ``` cpp
 void D::glorp() {
+  x++;              // OK, B::x hides V::x
+  f();              // OK, B::f() hides V::f()
   y++;              // error: B::y and C's W::y
   g();              // error: B::g() and C's W::g()
 }
 ```
 An explicit or implicit conversion from a pointer to or an expression
 designating an object of a derived class to a pointer or reference to
 one of its base classes shall unambiguously refer to a unique object
 representing the base class.
+[*Example 4*:
 ``` cpp
 struct V { };
 struct A { };
 struct B : A, virtual V { };
 void g() {
   D d;
   B* pb = &d;
   A* pa = &d;       // error: ambiguous: C's A or B's A?
+  V* pv = &d;       // OK, only one V subobject
 }
 ```
 — *end example*]
+[*Note 6*: Even if the result of name lookup is unambiguous, use of a
+name found in multiple subobjects might still be ambiguous
+[[conv.mem]], [[expr.ref]], [[class.access.base]]. — *end note*]
+[*Example 5*:
 ``` cpp
 struct B1 {
   void f();
   static void f(int);

Diff to HTML by rtfpessoa