2.068.0 regression?

[Timon Gehr via Digitalmars-d]

On 08/20/2015 10:06 PM, deadalnix wrote:
> On Thursday, 20 August 2015 at 10:46:18 UTC, Timon Gehr wrote:
>> On 08/20/2015 05:55 AM, Andrei Alexandrescu wrote:
>>>
>>> We need to fix the implementation. We can't promote imports that hide
>>> local symbols. -- Andrei
>>
>> Great! We should probably agree on the precise new semantics first
>> though.
>>
>> The current viable proposals in the bug report are:
>>
>> - The symbols declared in the module at any scope nesting depth hide
>> the symbols in the local import, but all symbols in imports in
>> enclosing scopes overload against each other.
>>
>> - No hiding of imported symbols by less deeply nested ones; enclosing
>> scopes are treated the same way as imports.
>>
>> I'm not sure what's better. I think Scala does something similar to
>> the second proposal.
>
> Yes, I'd advocate for the first one for 2 reasons:
>   - User has full control over module symbol, but may not have the same
> over imported ones. We'd like to avoid hijacking local symbols from
> imports as much as possible.

The second proposal allows for strictly fewer cases of hijacking (it 
also avoid those cases where a local symbol in an outer scope hides a 
locally imported symbol), and the usual cross-scope overload resolution 
semantics would apply. (So even if there is a name clash, it usually 
wouldn't matter for functions and/or templates.)

I do think it can be confusing if a symbol in a less deeply nested scope 
can hide a symbol imported in a more deeply nested scope.

>   - We'd like to be able to lazy import as much as possible. If import
> can hijack,

I assume what you mean is if it can cause a compiler error due to 
ambiguity in cross-scope overloading.

> then it is necessary to process them at least enough to be
> able to do first level lookup, even if the import is not used.

Makes sense. So the scenario we are looking at here is basically local 
imports in aggregate scopes, such that the imported symbols are not used 
in method signatures? Are those common enough to improve performance 
sufficiently to justify influencing the choice of best semantics? (There 
are 0 cases in my own code.)