Pathological import symbol shadowing

[Timon Gehr]

On 18.11.20 17:23, Mathias LANG wrote:
> On Friday, 13 November 2020 at 22:57:03 UTC, H. S. Teoh wrote:
>>
>> 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
> 
> Wouldn't *that* allow hijacking? Unless of course you remove implicit 
> conversions of parameters. If you have a `void foo(short)` in a module, 
> and you're using it from your main like so: `foo(42);`, then suddenly, 
> if overload sets were merged, another import at the same level could 
> introduce `void foo(int)`, which would be a better match, and hijack the 
> call, instead of creating an error as done currently.

How it should work:

- Do a lookup in the current module.
- If name is not found, figure out which (possibly nested) imports are 
in scope.
- Use the same standard overload resolution that is used for 
module-scope imports on those imports.