On 08/20/2015 01:20 AM, deadalnix wrote:
> On Wednesday, 19 August 2015 at 23:18:04 UTC, Timon Gehr wrote:
>> On 08/20/2015 01:06 AM, Dicebot wrote:
>>> On Wednesday, 19 August 2015 at 22:33:23 UTC, Timon Gehr wrote:
>>>> It's a bug in local imports. This is the ticket:
>>>> https://issues.dlang.org/show_bug.cgi?id=10378
>>>
>>> Seems to fit into existing shadowing semantics.
>>
>> There's no precedent for symbols shadowed by imports.
>>
>>> If this is a bug we may need a new spec.
>>
>> I believe local imports were first implemented without paying any
>> attention to shadowing. I think the broken semantics implemented in
>> DMD without a sufficient up-front design were then back-ported into
>> the documentation at some point. This still happens too often. This is
>> the JavaScript style of language design.
>
> import should NEVER shadow local symbols.

And yet for some reason this obviously broken behaviour is now documented as intended in the official language documentation.

http://dlang.org/module.html, look for "Scoped Imports".

"The imports are looked up to satisfy any unresolved symbols at that scope. Imported symbols may hide symbols from outer scopes."


On that same page:

"Modules offer several guarantees:
    [...]
    ● If a module C imports modules A and B, any modifications to B will not silently change code in C that is dependent on A."

On Wednesday, 19 August 2015 at 23:29:26 UTC, Timon Gehr wrote:
> On 08/20/2015 01:20 AM, deadalnix wrote:
>> On Wednesday, 19 August 2015 at 23:18:04 UTC, Timon Gehr wrote:
>>> On 08/20/2015 01:06 AM, Dicebot wrote:
>>>> On Wednesday, 19 August 2015 at 22:33:23 UTC, Timon Gehr wrote:
>>>>> It's a bug in local imports. This is the ticket:
>>>>> https://issues.dlang.org/show_bug.cgi?id=10378
>>>>
>>>> Seems to fit into existing shadowing semantics.
>>>
>>> There's no precedent for symbols shadowed by imports.
>>>
>>>> If this is a bug we may need a new spec.
>>>
>>> I believe local imports were first implemented without paying any
>>> attention to shadowing. I think the broken semantics implemented in
>>> DMD without a sufficient up-front design were then back-ported into
>>> the documentation at some point. This still happens too often. This is
>>> the JavaScript style of language design.
>>
>> import should NEVER shadow local symbols.
>
> And yet for some reason this obviously broken behaviour is now documented as intended in the official language documentation.
>
> http://dlang.org/module.html, look for "Scoped Imports".
>
> "The imports are looked up to satisfy any unresolved symbols at that scope. Imported symbols may hide symbols from outer scopes."
>
>
> On that same page:
>
> "Modules offer several guarantees:
>     [...]
>     ● If a module C imports modules A and B, any modifications to B will not silently change code in C that is dependent on A."

WTF are we backporting implementation madness in the spec rather than fixing it ?

On 8/19/15 7:29 PM, Timon Gehr wrote:
> On 08/20/2015 01:20 AM, deadalnix wrote:
>> On Wednesday, 19 August 2015 at 23:18:04 UTC, Timon Gehr wrote:
>>> On 08/20/2015 01:06 AM, Dicebot wrote:
>>>> On Wednesday, 19 August 2015 at 22:33:23 UTC, Timon Gehr wrote:
>>>>> It's a bug in local imports. This is the ticket:
>>>>> https://issues.dlang.org/show_bug.cgi?id=10378
>>>>
>>>> Seems to fit into existing shadowing semantics.
>>>
>>> There's no precedent for symbols shadowed by imports.
>>>
>>>> If this is a bug we may need a new spec.
>>>
>>> I believe local imports were first implemented without paying any
>>> attention to shadowing. I think the broken semantics implemented in
>>> DMD without a sufficient up-front design were then back-ported into
>>> the documentation at some point. This still happens too often. This is
>>> the JavaScript style of language design.
>>
>> import should NEVER shadow local symbols.
>
> And yet for some reason this obviously broken behaviour is now
> documented as intended in the official language documentation.
>
> http://dlang.org/module.html, look for "Scoped Imports".
>
> "The imports are looked up to satisfy any unresolved symbols at that
> scope. Imported symbols may hide symbols from outer scopes."
>
>
> On that same page:
>
> "Modules offer several guarantees:
>      [...]
>      ● If a module C imports modules A and B, any modifications to B
> will not silently change code in C that is dependent on A."

We need to fix the implementation. We can't promote imports that hide local symbols. -- Andrei

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.

On 08/20/2015 12:46 PM, Timon Gehr wrote:
>
> - No hiding of imported symbols by less deeply nested ones; enclosing
> scopes are treated the same way as imports.

(for overloading, not for lookup.)

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.
 - We'd like to be able to lazy import as much as possible. If import can hijack, 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.

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.)

On Thursday, 20 August 2015 at 20:27:58 UTC, Timon Gehr wrote:
>>   - 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.
>

Yes, but eve if it doesn't, one need to do a lookup in the imports to check, which is undesirable.

>> 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.)

On the long run, it is typical for code to have unused imports, especially since we have no linter to warn about them.

On 08/20/2015 11:00 PM, deadalnix wrote:
> On Thursday, 20 August 2015 at 20:27:58 UTC, Timon Gehr wrote:
>>>   - 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.
>>
>
> Yes, but eve if it doesn't, one need to do a lookup in the imports to
> check, which is undesirable.
>
>>> 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.)
>
> On the long run, it is typical for code to have unused imports,
> especially since we have no linter to warn about them.
>

I think this is a very weak point, so I didn't consider it.

Even if an import is unused, if there is at least one lookup of some identifier from any different module, it will have to be analyzed.

Also, in the long run, we'll have the linter. Given a front end, it's exceedingly simple to create.

On 08/21/2015 03:51 AM, Timon Gehr wrote:
>
> Even if an import is unused, if there is at least one lookup of some
> identifier from any different module, it will have to be analyzed.

(But not /transitively/. I think this is where the gains of lazy imports come from.)