mixin bug?

[Engine Machine via Digitalmars-d-learn]

On Thursday, 11 August 2016 at 21:25:20 UTC, sldkf wrote:
> On Thursday, 11 August 2016 at 20:27:01 UTC, Engine Machine 
> wrote:
>> This requires F2 to know the future. It also forces it to use 
>> a specific bar. I want inheritance like logic.
>
> You are goind to hit a wall. Template programming is not OOP.
> I'm not even sure that reflection would work in order to 
> determine the most "recent" overload.

Well, duh, it is not oop, but that doesn't mean it doesn't have 
similar abstractions, you need to read between the lines a bit 
more.

>> 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.
>
> This is the only issue I see: "It seems like D is trying 
> to...". We need to know exactly what D does: 
> https://issues.dlang.org/show_bug.cgi?id=16376.

It would be nice if D would bind the function calls lazily, so to 
speak, that is all I'm saying. This way we can get 
polymorphic/oop like behavior, if you will.

template A(T)
{
     void Bark() { writeln("Ruff Ruff"); }
}

template B(T)
{
     mixin A!T;
     void Talk() { Bark(); }
}

template Duck(T)
{
     mixin B!T;
     private void Bark() { writeln("Quack"); }
}


this is a contrived and misleading example if you take it 
seriously.

But Duck.Talk(); should Quack. It would if D resolved Bark from 
Talk after the final "mixin". (In Duck, not in B). Else we are 
stuck with a barking duck.

What it seems to do is first evaluate the template A!T, then B!T, 
then Duck!T. Since B!T is evaluated first and plugged in to Duck, 
Talk is already resolved to use A!T.Bark. Rather, If Duck!T was 
evaluated first, D would understand that Bark was already defined 
and when Talk was added, it could have it use the bark defined in 
duck, rather than A.

This, would, of course, require a sort of Duck!T.B!T type, since 
B!T used inside of Duck would have a different Talk() than if it 
is not used in Duck.

Again, maybe the compiler is just to ignorant to do this as it is 
complex(might require flow analysis and all that stuff or just be 
an ill-defined problem in general).