Re: explicit specialization in non-namespace scope

[Nathan Myers <ncm@cygnus.com>]

Mark Mitchell wrote:
> 
> >>>>> "Nathan" == Nathan Myers <ncm@cygnus.com> writes: 
>     Nathan> It's still not clear that the above text applies to the
>     Nathan> case mentioned.  "In the namespace of which the enclosing
>     Nathan> class is a member" is satisified both outside and inside
>     Nathan> the class.  When it means to say "not in a class or in a
>     Nathan> block", it says "at namespace scope" or sometimes "in
>     Nathan> namespace scope"; these are changed from "at global scope"
>     Nathan> which is what it said before we had namespaces.  "In the
>     Nathan> namespace of" does not imply "only at namespace scope".
> 
> I can see the sense in your interpretation.  (After all, besides
> implementing the removal of this feature, I also implemented the
> feature in the first place...)

Yes, thank you, thank you!

> But, do you think this is legal:
> 
>   template <class T>
>   struct S {
>     template <class U>     void f(U);
>     template <>            void f(int);
>   };
> 
> even though:
> 
>  template <class T>
>  struct S {
>    template <class U>     void f(U);
>  };
> 
>  template <class T>
>  template <>
>  void S<T>::f(int);
> 
> is not?  The standard says:
> 
>   In an explicit specialization declaration for a member of a class tem-
>   plate or a member template that appears in namespace scope, the member
>   template and some of its enclosing class templates may  remain  unspe-
>   cialized,  except that the declaration shall not explicitly specialize
>   a class member template if  its  enclosing  class  templates  are  not
>   explicitly  specialized as well.
> 
> which doesn't say anything about specializations that are *not* in
> namespace scope, which would therefore lead one to think this rule
> does not apply.  So specializations of member templates in template
> classes are in fact required to be inline?  Seems odd to me, although
> I agree that the paragraph I quote adds credence to your point of view
> about the legality of in-class specializations.  Perhaps I had better
> get that code out of CVS, and reenable it.

Permitting only inline definitions of such specializations would 
indeed be perverse.  Incidentally, the paragraph (18) only addresses 
"declarations", not definitions, but the examples are of definitions.

I think it is clear that in nested specializations, only the inner
ones are allowed to be left unbound.  I don't think it was intended
to be a syntactic restriction, but a semantic one. 

>     >> I can also report that Digital cxx rejects explicit member
>     >> template specializations.
> 
>     Nathan> Digital is a poor choice of compilers to check
>     Nathan> conformance.
> 
> But EDG is a good choice, and it too complains on specializations in
> class scope.

Yes, I have written to them about this.

Nathan Myers
ncm@cantrip.org