May a member function template specialization have a different access level than the main template?

Question

An answer to a a question I had about deleting functions mentioned how member function templates can't be specialized at class scope. That led me to wonder if it's possible for a member function template specialization to have a different access level than the main template. In the code below, I'm trying to have a private specialization of a public member function template:

#include <iostream>

class Foo {
public:
  template<typename T>
  void func(T) { std::cout << "Public\n"; }

private:
  template<>
  void func<char>(char) { std::cout << "Private\n"; }

  friend int main();
};

int main()
{
  Foo f;
  f.func(10);
  f.func('a');
}

With the latest MSVC, this compiles, runs, and produces the expected output:

Public
Private

With g++ 4.8 and Clang 3.2, the code is rejected. Clang says this:

error: explicit specialization of 'func' in class scope
void func<char>(char) { std::cout << "Private\n"; }
     ^

Presumably g++ and Clang are using 14.7.3/2 of C++11 as the basis for their behavior, but I think there might be a little wiggle room, because 3.3.6/3 says that the global scope is a namespace, and the global namespace (indirectly) encloses the template specialization.

My question isn't about these parts of the Standard or about any of these compilers' behaviors, though, it's about whether it is possible for a member function template to have a specialization that has a different access level than the general template. For example, is it possible to have a public member function template and a private specialization of that template?

Answer 1

We can always do it manually.

Some random SFINAE machinery:

#include <iostream>
#include <utility>
#include <type_traits>

template<typename T> constexpr bool IsInt() { return std::is_same<T,int>::value; }
template<std::size_t>
struct SecretEnum {
  enum class hidden {};
};
template<bool b, int i=1> using EnableIf = typename std::enable_if<b,typename SecretEnum<i>::hidden>::type;

class Foo {
public:
  template<typename T, EnableIf< !IsInt<T>(), 1 >...>
  void func(T) { std::cout << "Public\n"; }

private:
  template<typename T, EnableIf< IsInt<T>(), 2 >...>
  void func(T) { std::cout << "Private with int\n"; }

  friend int main();
};

int main()
{
  Foo f;
  f.func(10);
  f.func('a');
}

now this trick does not work with clang because of how I did the SFINAE and method distinguishing last I checked. But that can be replaced with other similar tricks (like pointer based default arguments in the second argument -- replace EnableIf< IsInt<T>(), 2 >... with EnableIf< IsInt<T>(), 2 >* = nullptr or somesuch for clang. I just find it less appealing.)

So what is going on above? I have two different overloads for func. Both are template functions with one argument that is a T, and a pack of some secret enum whose type is valid if and only if T matches the IsInt<T>() or !IsInt<T>() test respectively. The type of the packs differ in the two cases (one if them is SecretEnum<2>::hidden, the other is SecretEnum<1>::hidden), so their signatures are sufficiently different to satisfy most C++11 compilers (clang considers them to be identical last I checked, generating errors, I believe clang is wrong).

When you invoke func<blah>, it checks to see which (if any) of the two func are appropriate. As their conditions are exact opposites of each other, only one of them is ever the proper one.

In effect, we are doing manual specialization.

In C++1y, we may be able to template<IsInt T> and template<IsNotInt T> if the stars align properly and the concepts lite that gets into the technical report lets this work.