Multiple alias this, what's the hold up?

[aliak]

On Wednesday, 19 June 2019 at 06:05:31 UTC, Jonathan Marler wrote:
> On Wednesday, 19 June 2019 at 05:53:42 UTC, Jonathan M Davis 
> wrote:
>> On Tuesday, June 18, 2019 10:09:24 PM MDT Mike Franklin via 
>> Digitalmars-d wrote:
>>> On Tuesday, 18 June 2019 at 22:51:51 UTC, Jonathan M Davis 
>>> wrote:
>>> > It definitely looks like a DIP would be required for 
>>> > multiple alias this-es to become a thing, and whatever was 
>>> > in the DIP would have to convince Walter that it doesn't 
>>> > have the problems that multiple inheritance has.
>>>
>>> DIP66 (https://wiki.dlang.org/DIP66) was already created and 
>>> approved.  Did you have something else in mind?
>>
>> Given Walter's more recent statements on the matter, it 
>> doesn't sound like it's approved anymore. He's repeatedly 
>> compared having multiple alias this-es to multiple inheritance 
>> and expressed that it's a bad idea.
>>
>> - Jonathan M Davis
>
> It's fair to say that multiple alias this and multiple 
> inheritance have similarities, but some have argued that the 
> "bad parts" of multiple inheritance don't apply to 'alias this' 
> (i.e. the "Diamond Problem").  I'm hoping Walter will reveal 
> what problems he claims apply to both as I haven't seen anyone 
> else point them out yet.

That's not to say that alias this itself doesn't have its design 
problems (i.e. searchability is hard - but that can be fixed by 
changing the syntax a bit), and there's this gotcha:

class A { int i; void f() { writeln(i); } }
class B {
     A a;
     alias a this;
}

void main() {
     auto b = new B();
     if (b !is null) {
         b.f; // Wait what? - proceed to spend days going crazy.
     }
}

And then you have at least the problem that any implicit 
behaviour comes with - traceability.

Question: can the compiler issue an Error instead of segfaulting 
when directing flow to a reference type alias this member? It 
would make bug tracing the gotcha above a million times more easy.

But I am also curious about what the overlapping problems with MI 
are:

With regards to implementation details, the diamond problem 
errors out, and the layout problem is defined by member layout, 
which is also solved. And implicitness is desirable in some cases.

Also remember, it's "prefer" composition over inheritance. Not 
"never use". As always, there's a balance and it depends on the 
situation.