Pathological import symbol shadowing

[H. S. Teoh]

Just ran into this today:

	void main() {
		int[string] aa;
		int x;

		x = aa.get("abc", 123);	// OK

		import std;
		x = aa.get("abc", 123);	// Error: template std.net.curl.get cannot deduce function from argument types ...

		import std, object;
		x = aa.get("abc", 123);	// OK
	}

I know there's technically an explanation of this in terms of how the
compiler implements import, but seriously, this is extremely annoying
and confusing behaviour.  Especially because the symbol being hijacked
comes from the implicitly-imported object.d.  Newbies wouldn't even
*know* where to look if they encountered this error.

D's import implementation was supposed to be designed to prevent symbol
hijacking, but in this case it's falling flat on its face.

Why can't we make it so that symbols that aren't explicitly named on the
import line would add to existing overload sets instead of replacing
them?


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.