Title
Nested type of non-dependent base
Status
cd3
Section
13.8.3.2 [temp.dep.type]
Submitter
Johannes Schaub

Created on 2012-02-26.00:00:00 last changed 90 months ago

Messages

Date: 2013-04-15.00:00:00

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

Date: 2012-10-15.00:00:00

Proposed resolution (October, 2012):

[Some existing uses of the term “member of the current instantiation” are consistent with the definition in 13.8.3.2 [temp.dep.type] paragraph 4; others are intended to refer to members of the “current instantiation,” as defined in paragraph 1. The following resolution changes the latter to use the phrase “member of a class that is the current instantiation.”]

  1. Change 13.8.3.2 [temp.dep.type] paragraph 4 as follows:

  2. A name is a member of the current instantiation if it is

    • An unqualified name that, when looked up, refers to at least one member of a class that is the current instantiation or a non-dependent base class thereof. [Note: This can only occur when looking up a name in a scope enclosed by the definition of a class template. —end note]

    • A qualified-id in which the nested-name-specifier refers to the current instantiation and that, when looked up, refers to at least one member of a class that is the current instantiation or a non-dependent base class thereof. [Note: if no such member is found, and the current instantiation has any dependent base classes, then the qualified-id is a member of an unknown specialization; see below. —end note]

    • An id-expression denoting the member in a class member access expression (7.6.1.5 [expr.ref]) for which the type of the object expression is the current instantiation, and the id-expression, when looked up (_N4868_.6.5.6 [basic.lookup.classref]), refers to at least one member of a class that is the current instantiation or a non-dependent base class thereof. [Note: if no such member is found, and the current instantiation has any dependent base classes, then the id-expression is a member of an unknown specialization; see below. —end note]

    [Example: ... —end example]

    A name is a dependent member of the current instantiation if it is a member of the current instantiation which, when looked up, refers to at least one member of a class that is the current instantiation.

  3. Change 13.8.3.2 [temp.dep.type] paragraph 5 as follows:

  4. A name is a member of an unknown specialization if it is

    • A qualified-id in which the nested-name-specifier names a dependent type that is not the current instantiation.

    • A qualified-id in which the nested-name-specifier refers to the current instantiation, the current instantiation has at least one dependent base class, and name lookup of the qualified-id does not find any member of a class that is the current instantiation or a non-dependent base class thereof.

    • An id-expression denoting the member in a class member access expression (7.6.1.5 [expr.ref]) in which either

      • the type of the object expression is the current instantiation, the current instantiation has at least one dependent base class, and name lookup of the id-expression does not find a member of a class that is the current instantiation or a non-dependent base class thereof; or

      • the type of the object expression is dependent and is not the current instantiation.

  5. Change 13.8.3.2 [temp.dep.type] paragraph 8 as follows:

  6. A type is dependent if it is

    • ...

    • a nested class or enumeration that is a dependent member of the current instantiation,

    • ...

  7. Change 13.8.3.3 [temp.dep.expr] paragraph 3 as follows:

  8. An id-expression is type-dependent if it contains

    • ...

    or if it names a static data dependent member of the current instantiation that has is a static data member of type “array of unknown bound of T” for some T (13.7.2.5 [temp.static]). Expressions of the following forms...

  9. Change 13.8.3.4 [temp.dep.constexpr] paragraph 2 as follows (assumes the base text is as modified by issue 1413):

  10. An id-expression is value-dependent if:

    • it is a name declared with a dependent type,

    • it is the name of a non-type template parameter,

    • it names a member of an unknown specialization,

    • it names a static data member of the current instantiation that is a dependent member of the current instantiation and is not initialized in a member-declarator,

    • it names a static member function that is a dependent member of the current instantiation, or

    • it is a constant with literal type and is initialized with an expression that is value-dependent.

    Expressions of the following form...

  11. Change 13.8.3.4 [temp.dep.constexpr] paragraph 5 as follows (assumes the base text is as modified by issue 1413):

  12. An expression of the form &qualified-id where the qualified-id's nested-name-specifier names a dependent member of the current instantiation is value-dependent.
Date: 2012-02-26.00:00:00

Even though A::C is a nested type and member of the current instantiation, and thus dependent by the rules of 13.8.3.2 [temp.dep.type] paragraph 8, there does not seem to be a good reason for making it so:

  struct B {
   struct C { };
  };

  template<typename T> struct A : B {
   A::C c;
  };
History
Date User Action Args
2014-03-03 00:00:00adminsetstatus: drwp -> cd3
2013-10-14 00:00:00adminsetstatus: dr -> drwp
2013-05-03 00:00:00adminsetmessages: + msg4427
2013-05-03 00:00:00adminsetstatus: tentatively ready -> dr
2012-11-03 00:00:00adminsetmessages: + msg4079
2012-11-03 00:00:00adminsetstatus: open -> tentatively ready
2012-02-26 00:00:00admincreate