http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3867.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3730.html

There is a closed (extension status) Core issue for this, see Core issue 1077.

This is a proposal to allow specializing templates from within a different namespace. The motivation is that when we declare a new class, it is natural to want to provide associated template specializations. For example, it is really painful that whenever I declare a class, I need to leave my namespace and enter namespace std just to specialize std::less as shown below

  namespace A {
    namespace B {
      class C {...};
    }
  }

  namespace std {
    template <>
    struct less<C> : binary_function <C, C, bool> {
       bool operator() (const C & x, const C & y) const {...}
   };
  }

  namespace A {
    namespace B {
      ... // Continue working in A::B
    }
  }

 
  namespace A {
    namespace B {
      class C {...};
      template <>
      struct ::std::less<C> : binary_function <C, C, bool> {
        bool operator() (const C & x, const C & y) const {...}
      };
    ... // Continue working in A::B
    }
  }

Bristol 2013: Stroustrup expressed concern about unqualified name lookup in the specializations, and Voutilainen thought that that just might be the reason why the current rules don't allow it. Gottschling voiced concern about the implementation impact, and Voutilainen suggested asking for a quick review of the overall idea from Spicer. Austern thought that this could be palatable if it's expressed as a set of rewrite rules. Spertus asked about an alternative which is to be able to open another namespace without having to exit the current namespace. This alternative didn't gain success. Spertus to write a paper.

In Chicago 2013, EWG guidance was to work based on the current proposal N3730 without the facility of specializing a namespace-scoped template from inside a class.

Discussed in Rapperswil 2014.

Gregor and Vandevoorde expressed concern about changing name lookup, and thought that the problem space needs the help of Core experts. Dos Reis expressed concern about expanding the need to do more tentative parsing to resolve ambiguities. Stroustrup requested further study in order to explore the possibilities to find a solution that doesn't cause issues with lookup, and Spertus agreed that further exploration seems wise.

EWG encouraged working further on the problem, looking at alternative solutions.