Question

Consider the following class:

class Foo
{
  enum Flags {Bar, Baz, Bax};

  template<Flags, class = void> struct Internal;

  template<class unused> struct Internal<Bar, unused> {/* ... */};
  template<class unused> struct Internal<Baz, unused> {/* ... */};
  template<class unused> struct Internal<Bax, unused> {/* ... */};
};

The class outline above compiles and functions as expected when tested on VC++ 2010 and Comeau C++. However, when Foo is made into a template itself, the above snippet breaks under VC++ 2010.

For example, the following snippet:

template<class> class Foo
{
  // Same contents as the original non-templated Foo.
};

Yields the following error class:

C2754: 'Foo<<unnamed-symbol>>::Internal<Bar,unused>' : a partial specialization cannot have a dependent non-type template parameter
C2754: 'Foo<<unnamed-symbol>>::Internal<Baz,unused>' : a partial specialization cannot have a dependent non-type template parameter
C2754: 'Foo<<unnamed-symbol>>::Internal<Bax,unused>' : a partial specialization cannot have a dependent non-type template parameter

---

1. Can someone explain what is going on here in plain English?
2. How can I fix this (i.e., keep internal pseudo-explicit specializations in a templated Foo) on VC++ 2010?

Answer 1

How can I fix this (i.e., keep internal pseudo-explicit specializations in a templated Foo) on VC++ 2010?

You can make the enumeration type non-dependent by declaring it in a non-template base class (C++03 made nested classes dependent in #108 but that doesn’t include enumeration, but even if, such code would still be legal).

struct FooBase { 
  enum Flags {Bar, Baz, Bax};
};

template<class> class Foo : public FooBase {
  template< ::FooBase::Flags, class = void > struct Internal;
  // same other stuff ...
};

The “error class” link already gives a description of the intended cases where the error should be risen. The error thinks that all dependent types are forbidden, but in fact this is what the Standard says:

The type of a template parameter corresponding to a specialized non-type argument shall not be dependent on a parameter of the specialization.

So even if the name Flags would be somehow dependent, that wouldn’t make it ill-formed as long as it doesn’t depend on a parameter of the specialization like in the example of your “error class” link.