Pathological import symbol shadowing

[Timon Gehr]

On 13.11.20 23:57, H. S. Teoh wrote:
> 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.
> ...

Told you so. :P
https://issues.dlang.org/show_bug.cgi?id=10378
https://issues.dlang.org/show_bug.cgi?id=17589


> 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?
> 

It should just use the standard import rules with overload sets. Then 
the code above would just work and no hijacking would be possible.