Multiple alias this and alias this in classes

[RazvanN]

On Monday, 16 January 2023 at 23:27:39 UTC, deadalnix wrote:
> During a recent discussion with several D folks, several 
> people, including Walter told ma that the situation with 
> multiple alias this and alias this in classes was hopelessly 
> broken. I suggested it needed to be either fixed or removed.
>
> However, during this discussion, I took the fact it was 
> hopelessly broken for granted. But it doesn't appear to me that 
> this is obvious. Can someone familiar with the topic care to 
> explain or point me to a link where this case was made already?
>
> On an asside, I implemented both multiple alias this and alias 
> this for classes in SDC. Because these feature were never 
> completed in DMD, I had to extrapolate to figure out what the 
> semantic should be, and this is what I came up with.
>
> 1/ Alias this is used in two contextes: casts and identifier 
> resolution.
> 2/ For struct, it just follow the expected rule for cast and 
> resolution, if these rule succeed, then nothing more happen. If 
> they fail, then the operation is repeated again with all the 
> declared alias this. If the number of valid result is 1 and 
> exactly 1, then it is used. If the number of valid result is 0 
> or greater than 1, then an error is emitted.
> 3/ For classes, lookups ignore alias this and walk up the 
> parent stack, still ignoring any alias this. If that fails, 
> then all the alias this from this class and its parent are run 
> at once, and if the number of valid result is 1, then this is 
> fine, if it is 0 or greater than 1, then an error is emitted. 
> The same is done for casts.
>
> I think this semantic is reasonable. But I have to say I did 
> not put a ton of though into it, so maybe there is a big fatal 
> flaw I'm overlooking.

This is what I implemented for single alias this in 
https://github.com/dlang/dmd/pull/8815 , however, Walter turned 
it down:
https://github.com/dlang/dmd/pull/8815#issuecomment-439670478 .

Then when we discussed it he said that this is complicated and it 
will become much more complicated with multiple alias this.

At the time when I made the PR I had the same train thought as 
you, since I was planning on implementing multiple alias this (I 
just wanted to fix all the single alias this bugs before doing 
it). However, there still are tons of other bugs or rough edges 
with alias this. Just one example: if you have a = b with a and b 
both having alias this and typeof(a) != typeof(b) it's not very 
clear if this should be rewritten to a.aliasthis = b, or a = 
b.aliasthis or a.aliasthis = b.aliasthis, assuming that any 
combination of those is valid code; not to mention that if any of 
those define an opAssign things get more complicated even 
further. I'm not saying that this is not solvable, it's just that 
currently it is not defined and it's not obvious how these should 
be fixed. So from my perspective, we still need to flesh out 
alias this before even thinking about multiple alias this.

So from that perspective, I assume that Walter's view is that 
alias this was a mistake (since it turns out there are a lot of 
cases that were not considered and it's not obvious how to fix 
them) and going forward with multiple alias this will just 
exponentially multiply those issues.

Best regards,
RazvanN