[Bug c++/13594] [3.4 Regression] namespace association vs. templates part two

[aoliva at gcc dot gnu dot org]

------- Additional Comments From aoliva at gcc dot gnu dot org  2004-01-07 19:43 -------
Ok, this is tricky.  I can't quite tell what the meaning of attribute strong is
to be in the following two cases:

namespace foo { template <class T> class bar; }
namespace fool { template <class T> class bar; using namespace foo
attribute((strong)); }

it appears to me that the declarations of bar are not to be unified in this
case.  However, if I rewrite it like this:

namespace foo { template <class T> class bar; }
namespace fool { using namespace foo attribute((strong)); template <class T>
class bar; }

then it appears to me that the redeclaration of bar should resolve to foo::bar,
instead of introducing a new declaration in fool that hides foo::bar.

In fact, even name hiding is not the correct behavior in all cases.  Consider,
for example:

namespace foo { template <class T> void bar(T); }
namespace fool { template <class T> void bar(T, T); using namespace foo
attribute((strong)); }

should fool::bar(int) be valid, or should it be completely hidden by
fool:bar<T>(T,T)?  The behavior we have now is the latter, which is exactly what
causes the vector specialiation for swap to not be used, and to fail overload
resolution, in the testcase Richard Sandiford mentioned.  Since there are
definitions of swap in namespace std in <algorithm> and <string>, those in
__gnu_norm are never considered as part of namespace std, so we can't specialize
them as if they were in namespace std, so the extension fails to implement its
intended purpose (per the manual).

The reason unqualified lookups find the correct version is obviously Koenig
lookup, but it doesn't apply to qualified lookups.

So the decision we have to take now is how to address cases in which a name is
declared (and maybe defined) in more than one (associated or specified) namespace.

It appears to me that the right strategy is to look a name up in all associated
namespaces and, for functions, build an overload and, for classes, attempt some
form of unification or simply error out in case the name is multiply defined. 
The latter would rule out forward declarations of templates in the official (as
opposed to implementation) namespace.  Can we live with this?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-01-07 19:43:52
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13594