This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 114a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-04-18
[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to DR at the February, 2021 meeting.]
[Accepted as a DR at the February, 2019 meeting.]
The first four paragraphs of 6.4.7 [basic.scope.class] are somewhat redundant. In particular:
The normative paragraphs are 4 and 2.
Paragraph 1 is subsumed by paragraph 4.
Paragraph 3 follows from existing rules for name hiding.
This is editorial issue 1169.
Proposed resolution (November, 2018):
In 6.4.7 [basic.scope.class], delete paragraph 1, move paragraph 4 to the beginning, and make paragraph 3 a note:
The potential scope of a name declared in a class consists not only of the declarative region following the name's point of declaration, but also of all complete-class contexts (11.4 [class.mem]) of that class.The potential scope of a declaration that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, and member function definitions, including the member function body and any portion of the declarator part of such definitions which follows the declarator-id, including a parameter-declaration-clause and any default arguments (9.3.4.7 [dcl.fct.default])).
A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule.
[Note: A name declared within a member function hides a declaration of the same name whose scope extends to or past the end of the member function's class (_N4868_.6.4.10 [basic.scope.hiding]). —end note]
The potential scope of a declaration that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, and member function definitions, including the member function body and any portion of the declarator part of such definitions which follows the declarator-id, including a parameter-declaration-clause and any default arguments (9.3.4.7 [dcl.fct.default])).
Additional note, March, 2019:
The resolution emoves the rule that a class member name can be found by unqualified lookup prior to its point of definition in complete-class contexts, at least in non-defining member declarations:
struct X {
void f(int n = k); // was valid, now ill-formed
static int k;
};
Relatedly, the "member definitions" rule (formerly p4, now p2) that was used to justify the removal of p1 is wrong (both before and after that change):
struct A {
void f(B b) {} // was always (incorrectly) valid
struct B {};
};
For these reasons, this issue has been returned to "drafting" status.