🚀 go-pugleaf

You did NOT understand it.

There is NO "dependency into the order of declaration".

The reason that the language should choose N1::f() is that it's in the SAME namespace
as N1::g(), and NOT because it's decalred BEFORE N2::f().

That's why I compared it to the "global function versus member function" function
resolution.

AGAIN, the example ( but re-ordered ):

namespace N1 {
void g();
};

namespace N2 {
void f();
};

namespace N1 {
void f();
};

using namespace N1;
using namespace N2;

void N1::g() {
f(); // here is the BUG in the language. should use N1::f().see below.
}

And AGAIN, The paralel "global function versus member function" example :

void f();

class X {
void f();
void g();
};

void X::g() {
f(); // here it's OK. calls X::f() and NOT ::f()
}

Think of a namespace as a class, and it will all be clear.

The implementation of namespaces, BTW, is exactly this, from the point of view of
name resolution ( I know that's it's NOT exactly the same, so please don't say
anything :-) ).

A SHORT explanation :

A namespace can't have two, for instance, "void f()", even in differant source files
( the linker will shout ). This is the same for classes ( in my example, class X ).
So there is NO way to make a WRONG choise. Either choose the function in your own
namespace OR try to choose another function in another namespace.

So the language can CHOOSE to use N1::f() over N2::f() simply because THEY BOTH ARE
IN THE SAME NAMESPACE. This is ALREADY done in classes, in X::g() the choosen
function is X::f() and NOT ::f(), simply because X::g() and X::f() are in the same
SCOPE ( I'm repeating myself :-) ).

This WILL solve your problem of the template operator function, if ALL the USERS of
your code will be in the SAME namespace as your CODE ( which is NOT a hard
requirment. better than others, anyway ), and the language will CHOOSE your templates
OVER STL's, SIMPLY because they are in the SAME namespace.

HTH.

Is there somebody willing to send this correction to the draft to the standrad
committe ?

-- Etay Bogner,
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]