Multiple alias this and alias this in classes

[Timon Gehr]

On 1/17/23 13:17, RazvanN wrote:
> 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 .
> ...

Well, his suggestion was basically to treat the base class just like 
another alias this, just like I have also suggested in my other post in 
this thread.

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

It's not more complicated, it's basically the same thing (or maybe even 
simpler because you don't have the complication from inheritance). 
Currently you can inherit alias this from a base class and have your own 
alias this also. This is just a slightly restricted form of 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

As far as I can tell, all of the cases you mention are in fact covered 
by the specification in the OP. If there are multiple ways to make it 
work, it should not work.