[cfe-dev] Is clang name lookup too restrictive for dependent base classes?

[John McCall]

On Feb 11, 2010, at 3:03 AM, Enea Zaffanella wrote:
> Douglas Gregor wrote:
>> g++ is too permissive. This is two-phase name lookup, which Clang is very strict about.
> 
> Is there any plan to increase compatibility with g++ by adding some sort 
> of "relaxed mode" option?

No.  It's certainly technically possible, but it's not a priority for the project, assuming we even want to do it.

The fear is that if we add a relaxed mode switch, everyone will just add -frelaxed-mode or whatever and nobody will get the advantage of all these wonderful diagnostics we can emit in template definitions. :)

> I checked clang source for a reference to the standard and I found the 
> following (Sema/SemaTemplate.cpp):
> 
>     // C++0x [temp.expl.spec]p17:
>     //   A member or a member template may be nested within many
>     //   enclosing class templates. In an explicit specialization for
>     //   such a member, the member declaration shall be preceded by a
>     //   template<> for each enclosing class template that is
>     //   explicitly specialized.
>     // We interpret this as forbidding typedefs of template
>     // specializations in the scope specifiers of out-of-line decls.
> 
> Both g++ and Comeau will refuse the example above if the "template <>" 
> was omitted ... but I don't see a strong relation between this behavior 
> and the presence of a typedef name.

Without the template<>, the compiler doesn't realize you're declaring
an explicit specialization.  But the design of template parameters in the
language (and Doug can speak more to this) is that parameter clauses
are matched up with argument clauses in the declared name — that is,
you match angle brackets to angle brackets.  Using a typedef screws
up this matching because it means that parts of the name without
angle-brackets are supposed to matched against.

That's why the language requires it.  From a user-design point of view,
gcc's permissiveness on this goes a long way towards explaining why
nobody but language geeks understands how this matching is
supposed to work.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100211/dbc7efb9/attachment.html>