Pathological import symbol shadowing
timon.gehr at gmx.ch
Wed Nov 18 21:12:25 UTC 2020
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?
> 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
- Use the same standard overload resolution that is used for
module-scope imports on those imports.
More information about the Digitalmars-d