🚀 go-pugleaf

The problem might be the overloading rules BETWEEN namespaces.
If I remember correctly, the following example produces an error :

namespace N1 {
	void f();
	void g();
	};

namespace N2 {
	void f();	
	};

using namespace N1;
using namespace N2;

void N1::g() {
	f(); // here is the catch ( error )
	}

I think that the draft says that the call of "f" in N1::g() is ambiguous.
If not, and the language says that N1::f() should be called, all is well.

Anyways, The compiler should prefer N1::f() over the error ( again, if it's an error ).

The reason :

void f();

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

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

Since the language is smart enough to say that X::f() is "more-related" to X::g() than ::f()...

This is quite reasonable : namespaces are actually WIDER class definitions, such that can be split among 
several files. The functions have the namespace relationship in their names, exactly as member functions 
( => the mangled name of X::g() will contain somewhere that it belongs to namespace X ).

If I'm NOT wrong, meaning that overloading between namespaces IS ambigiuous, I guess that treating 
namespaces as WIDER classes will provide the answer to the discussed problem.

-- Etay Bogner,
-- ebogner@ird.scitex.com ( OLD ),
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.