mixin bug?

[Engine Machine via Digitalmars-d-learn]

On Thursday, 11 August 2016 at 19:05:58 UTC, sldkf wrote:
> 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.
>
Yes, but when we "mixin" again, bar then does exist. I see the 
mixin as a sort of copy and paste. We only paste in what doesn't 
exist. So the first time bar gets inserted in to F2, but then 
that bar doesn't get inserted in to F3 because it already exists.

Basically a mixin of a mixin is not logically a mixin. That makes 
no sense to me.

A mixin is suppose to behave a certain way, but when we do a 
mixin of a mixin we get behavior that doesn't behave the same way 
as a single mixin.


> 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:
>

I don't want to target F1.bar, I want foo to target future bar's.

It is like overloading, but for templates.

If you were doing overloading, and it called the base function 
instead, it wouldn't be overloading, would it?

> °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
> template F1(T){void bar() {writeln("Bar0");}}
>
> template F2(T)
> {
>    mixin F1!T FF1;
>    void foo() { FF3.bar; }
> }
>

This requires F2 to know the future. It also forces it to use a 
specific bar. I want inheritance like logic. Which is what we get 
when we mixin one deep, but when we go deeper, it breaks. I think 
this is a bug. It seems like D is trying to resolve things only 
after each mixin, rather than resolving after all nested mixins 
are evaluated.