Date: 2013-04-15.00:00:00

[Moved to DR at the April, 2013 meeting.]

Date: 2012-08-15.00:00:00

Proposed resolution (August, 2012):

Change 6.5.5.2 [class.qual] paragraph 2 as follows:

In a lookup in which the constructor is an acceptable lookup result function names are not ignored [Footnote: Lookups in which function names are ignored include names appearing in a nested-name-specifier, an elaborated-type-specifier, or a base-specifier. —end footnote] and the nested-name-specifier nominates a class C :

• if the name specified after the nested-name-specifier, when looked up in C , is the injected-class-name of C ( Clause 11 [class]), or

• in a using-declaration (9.10 [namespace.udecl]) that is a member-declaration, if the name specified after the nested-name-specifier is the same as the identifier or the simple-template-id's template-name in the last component of the nested-name-specifier,

the name is instead considered to name the constructor of class C ...

Date: 2022-02-18.07:47:23

In 6.5.5.2 [class.qual] paragraph 2,

In a lookup in which the constructor is an acceptable lookup result and the nested-name-specifier nominates a class C :

• if the name specified after the nested-name-specifier, when looked up in C , is the injected-class-name of C (Clause 11 [class]), or

• in a using-declaration (9.10 [namespace.udecl]) that is a member-declaration, if the name specified after the nested-name-specifier is the same as the identifier or the simple-template-id's template-name in the last component of the nested-name-specifier,

the name is instead considered to name the constructor of class C .

it is not clear what constitutes “an acceptable lookup result.” For instance, is

  struct S { } *sp = new S::S;

well-formed?

The intent of the wording was that S::S would refer to the constructor except in lookups that ignore the names of functions, e.g., in elaborated-type-specifiers and nested-name-specifiers. There doesn't seem to be a good reason to allow a qualified-id naming the injected-class-name. The alternative, i.e., only to find the constructor in a declarator, complicates parsing because the determination of whether the name is a type or a function would require lookahead.