Multiple alias this, what's the hold up?

[Amex]

On Sunday, 16 June 2019 at 06:08:54 UTC, Walter Bright wrote:
> On 6/15/2019 6:21 PM, Timon Gehr wrote:
>> In terms of lookup, the issues with multiple alias this are 
>> the same as the issues with multiple import declarations. 
>> Implicit conversions could use the same lookup rules, but 
>> there would need to be a way to disambiguate. The code in the 
>> compiler that implements import declarations is unlikely to be 
>> easily reusable.
>
> Multiple alias this is multiple inheritance. Generally, if you 
> find yourself wanting multiple inheritance, it's likely time to 
> rethink the data structures.

This is not true! Alias this is does not use inheritance at all. 
There is no vtable for alias this. It's purely compile time. It's 
purely to simplify dispatching.

https://dlang.org/spec/class.html#AliasThis

Says nothing about inheritance.

There is no diamond problem so I really have no idea what you are 
talking about.

Alias this is entirely for convinces and is only compile time.

The reason why the diamond problem is an issue is because it can 
occur without the compiler being able to determine that is is a 
problem(such as with plugins).

With alias this, the compiler always can determine what is going.

I think you are mistaken here. I could be wrong. Do you have 
proof of what you claim?


struct X
{
    int q;
    alias q this;
}


Where is the inherence in this code?

as far as the docs they simply say that we can treat any instance 
x of X as if we used x.q.

Hence, instead of having to write x.q all over the place we can 
write x.

How can this ever create a diamond problem? And if it did how 
would that not be caught at compile time?