mixin bug?

[sldkf via Digitalmars-d-learn]

On Thursday, 11 August 2016 at 17:56:47 UTC, Engine Machine wrote:
> template F1(T)
> {
>    void bar() { writeln("Bar0"); }
> }
>
> template F2(T)
> {
>    mixin F1!T;
>    void foo() { bar(); }
> }
>
> template F3(T)
> {
>    mixin F2!T;
>    void bar() { writeln("Bar1"); } // <- This bar should be 
> used for F2's foo!
>
> }
>
> struct F4(T)
> {
>     mixin F3!T;
> }
>
> (Or on can turn F3 in to a struct directly)
>
>
> Then f3.foo() calls bar from F0, not F3's bar! This seems like 
> a big bug! One expects the same behavior of mixins regardless 
> of mixin nesting.
>
> While you could argue that foo, when declared, is calling F0's 
> bar, this is not consistent with the view that mixin templates 
> only adds what is not there. I don't like the idea that calls 
> are resolved first come first serve as it means one can't 
> extend templates in a natural logical way.

I don't think it's a bug. F3's bar() doesn't exist yet in F2. 
Logically F1's one is called.

The language allows to alias a mixin so that a particular 
overload can be called. In you case you can really target F1.bar 
without problem:

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
template F1(T){void bar() {writeln("Bar0");}}

template F2(T)
{
    mixin F1!T FF1;
    void foo() { FF3.bar; }
}

template F3(T)
{
    mixin F2!T FF2;
    void bar() { writeln("Bar1");}
}

struct F4(T){mixin F3!T FF3;}
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

See https://dlang.org/spec/template-mixin.html#mixin_scope

However the specification doesn't say what is the rule that's 
applied. Even if it look logical that F1.bar() is chosen it has 
to be written somewhere.