http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46731
--- Comment #5 from Johannes Schaub <schaub-johannes at web dot de> 2010-12-01 14:39:18 UTC --- (In reply to comment #3) > Confirmed. EDG accepts it. > > But I would argue that g is bound at first stage name-lookup > and thus it is not a dependent name and thus the error is correct. It is bound at first stage name lookup because it's not a dependent name. Thus, it is transformed to class-member access because "g" is a non-static member of some class. It being bound at first stage name lookup doesn't IMO mean that you drop any analysis that would depend on instantiation semantics, it just means you do name lookup only in the definition as opposed to be in the instantiation. In this case what will happen: g -> (*this).g // found g in the definition context! -> (*this).g(); So, you have an implicit object parameter of type a&, and an implied object argument of lvalue of type "b<a>", that has a dependent base class. The validity of the call depends on template arguments, so you have to delay further analysis. This further analysis doesn't have to do with name lookup but with overload resolution. The committee clarified the issue by resolving DR 515, stating their intent to support this and similar code. It may require that you internally mark constructs as "instantiation dependent" that formally aren't marked as type/value dependent, just because its validity depends on facts you can only know when instatiating so that you know when walking over the AST top-down what you again need to check and what not. I've no idea about those internal compiler things. Active issue #1172 looks for proper wording to capture any such constructs in a formal way.
