Re: C++ PATCH: PR 13140

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Mark Mitchell <mark@codesourcery.com> writes:

| Benjamin Kosnik wrote:
| 
| > However, when we were presenting in Kona about namespace association,
| > nobody (Gaby, Bjarne, Daveed) could remember why this particular
| > behavior is required in the first place.
| > 
| > Any thoughts?
| 
| I talking about it with John Spicer before posting this patch (he was
| the one who pointed me at DR 275), but I didn't ask about the thinking
| behind it.
| 
| My guess is that explicit instantiations have the rule because
| specializations do.
| 
| I do think it makes sense that specializations have to be declared in
| the namespace where the template is located; that's an encapsulation
| idea.  I think the rationale for specialization in an enclosing
| namespace, rather than just the one in which it was declared, but not in
| some unrelated namespace, is that it means that a library can specialize
| its own templates, and, if properly declared, so can a program using
| that library, but some other third-party library in its own namespace
| can't mess with the templates from the first library.  That's presumably
| the reason for the rules around where you can define static data members
| and member functions (regardless of whether or not they are in templates).
| 
| My two cents,

What confuses people is that the following is permitted and used in
practice:

     namespace N {
        namespace M {
           void f();
           void g();
        }

        void M::f() { }
     }

     void N::M::g() { }

having a (long) list of special rules tend to go against the same very
idea of encapsulation too.  As I said, I haven't done any on it since
then, for I have been kept busy by more serious and major issues.  It
may very well be that nothing will happen about it, given the schedule
we've set for C++0x, and in particular EWG.

-- Gaby