So, as I implement more and more features of D, the question of identifier resolution pops up more and more, to the point it starts to become a problem.

Each feature that introduce new lookup is usually defined, but there is no definition of what are the priorities in between them, and how the should interact.

When resolving an identifier in an object, if local lookups fails, here are the possible fallback places where you look into:
 - parent class/interface (1)
 - alias this (1)
 - __outer (1)
 - UFCS (2)

That is for local symbols. This get even more tricky you put into the equation that one most likely want to register symbol from parent class/interface into the child scope as you wouldn't want an overridden method to resolve differently than a a non override one, but not other symbols.

Now let's consider the free symbol scenario. It can fallback in various ways as well:
 - this (1)
 - context (2)
 - with statement (2)
 - import (2)

And as for local symbols, fallback can recursively fallback into each others.

Here are the possible fallback:
 1 - parent class/interface
   - alias this
   - __outer
 2 - context
   - with statement
   - import
   - this

Sounds like we need to define some priorities here.

I had impression that general rule is "most inner scope takes priority" (with base classes being one "imaginary" scope above the current one). Are there any actual inconsistencies you have noticed or it just a matter of lacking matching spec entry?

On Wednesday, 17 September 2014 at 16:25:57 UTC, Dicebot wrote:
> I had impression that general rule is "most inner scope takes priority" (with base classes being one "imaginary" scope above the current one). Are there any actual inconsistencies you have noticed or it just a matter of lacking matching spec entry?

There is no inconsistencies because there is no spec.

On Wednesday, 17 September 2014 at 22:42:27 UTC, deadalnix wrote:
> On Wednesday, 17 September 2014 at 16:25:57 UTC, Dicebot wrote:
>> I had impression that general rule is "most inner scope takes priority" (with base classes being one "imaginary" scope above the current one). Are there any actual inconsistencies you have noticed or it just a matter of lacking matching spec entry?
>
> There is no inconsistencies because there is no spec.

Maybe in this case it is best to just look at what dmd does and add that to the spec (assuming what dmd does is sound, and makes sense).

On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander wrote:
> Maybe in this case

And in every case. DMD's behavior is correct because it consistent with DMD.

On 09/19/2014 12:06 AM, Brian Schott wrote:
> On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander wrote:
>> Maybe in this case
>
> And in every case. DMD's behavior is correct because it consistent with
> DMD.

???

On Thursday, 18 September 2014 at 23:14:41 UTC, Timon Gehr wrote:
> On 09/19/2014 12:06 AM, Brian Schott wrote:
>> On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander wrote:
>>> Maybe in this case
>>
>> And in every case. DMD's behavior is correct because it consistent with
>> DMD.
>
> ???

http://en.wikipedia.org/wiki/Gallows_humor

On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander
wrote:
> On Wednesday, 17 September 2014 at 22:42:27 UTC, deadalnix wrote:
>> On Wednesday, 17 September 2014 at 16:25:57 UTC, Dicebot wrote:
>>> I had impression that general rule is "most inner scope takes priority" (with base classes being one "imaginary" scope above the current one). Are there any actual inconsistencies you have noticed or it just a matter of lacking matching spec entry?
>>
>> There is no inconsistencies because there is no spec.
>
> Maybe in this case it is best to just look at what dmd does and add that to the spec (assuming what dmd does is sound, and makes sense).

Yeah this is exactly what I was asking about. I assumed that
deadlnix has done some research about it and found some specific
inconsistencies / issues - after all, it is not the only
implementation-defined feature he must have encountered :)

On Friday, 19 September 2014 at 10:59:24 UTC, Dicebot wrote:
> Yeah this is exactly what I was asking about. I assumed that
> deadlnix has done some research about it and found some specific
> inconsistencies / issues - after all, it is not the only
> implementation-defined feature he must have encountered :)

DMD does very bizarre things. I think I should write a DIP, but time is always running low...

Free goodie: when you import, all symbol are resolved via the expected import resolution mechanism. All ? No, the root package is imported in the local scope.

foo(int a) {
  import a.b.c;
  // a is now a package and not the parameter a anymore.
}

Am 21.09.2014 07:29, schrieb deadalnix:
> On Friday, 19 September 2014 at 10:59:24 UTC, Dicebot wrote:
>> Yeah this is exactly what I was asking about. I assumed that
>> deadlnix has done some research about it and found some specific
>> inconsistencies / issues - after all, it is not the only
>> implementation-defined feature he must have encountered :)
>
> DMD does very bizarre things. I think I should write a DIP, but time is
> always running low...
>
> Free goodie: when you import, all symbol are resolved via the expected
> import resolution mechanism. All ? No, the root package is imported in
> the local scope.
>
> foo(int a) {
>    import a.b.c;
>    // a is now a package and not the parameter a anymore.
> }

There are also funny little things like this one:
http://dpaste.dzfl.pl/aac84d5ffae8