[Bug c++/11828] [3.4/4.0 regression] qualified dependent name looked up too early

smcpeak at cs dot berkeley dot edu gcc-bugzilla@gcc.gnu.org
Mon Feb 21 19:12:00 GMT 2005

------- Additional Comments From smcpeak at cs dot berkeley dot edu  2005-02-21 02:41 -------
I question the apparent conclusion reached in this discussion.  The
reporter's testcase refers to


where 'a' has dependent type.

The conclusion so far is that 'f' is not dependent because it is
qualified.  The primary justification offered is that 14.6.2p1
mentions exactly two syntactic cases of dependent names:

  - function call with a simple 'identifier' as the function
  - operator in an expression

However, as discussed here and elsewhere
(e.g., http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html),
there is general consensus that the following forms also make
'f' dependent:

  - x->f(a)          // when x is a type-dependent expression
  - C::f(a)          // when C is a dependent type

Therefore, my interpretation is that the two cases given in 14.6.2 are
*not* exhaustive, but rather merely examples.  14.6.2 first gives some
general properties of dependent names (e.g., "... semantics which may
differ from one instantiation to another.") that clearly apply to more
situations.  And singles out unqualified names as a special
case---why would they be a special case if only unqualified names
could be dependent?

Now, it is true that the two additional generally-agreed-upon cases
above are "doubly" dependent: not only do they have arguments of
dependent type, but their receiver object or qualifier is also of
dependent type.  Consequently, the expressions are type-dependent
( p1, p3 resp.); but the standard never says that being part
of a type-dependent expression automatically makes the name dependent!
On the contrary, gives several counterexamples.  Moreover,
in the simple case "f(a)", 'f' is not a type-dependent expression, and
yet it is clearly a dependent name.

Extrapolating from the first few sentences of 14.6.2, it seems to me
that the following are exhaustive representatives of cases where the
name 'foo' is dependent:

A.  Cases where function overload resolution is performed, and
influenced by some type that might be dependent:

  A1. foo(a,b,c)
  A2. C::foo(a,b,c)
  A3. x->foo(a,b,c)
  A4. x->C::foo(a,b,c)

when a or b or c is a type-dependent expression.

B.  Cases where lookup involves traversing a class with dependent

  B1. C::foo
  B2. x->foo
  B3. x->C::foo

when C is a dependent type, or x is a type-dependent expression.

C.  Cases when the address of an overloaded function is matched to a
target type (13.4) that is dependent.  This would include all
variations of

  C.  [&][x->][C::]foo

where by brackets ([]) I mean optional component.

In all cases (except case C, I *think*) 'foo' could be a template-id,
and would still be dependent.  (Plus the case of operators in
expressions where an operand is a type-dependent expr.)

           What    |Removed                     |Added
                 CC|                            |smcpeak at cs dot berkeley
                   |                            |dot edu


More information about the Gcc-bugs mailing list