Looks good to me, and its even implemented in a compiler and known to be working!

On 1/17/23 00:27, deadalnix wrote:
> 
> 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.

No, this is how it should work. I guess those rules are inspired by how multiple imports/mixins work in D. It's a solved problem.

It's debatable whether one should treat inheritance like just another alias this for lookup (I have a slight preference for that). With your rules it's possible to hijack an alias this lookup on a child class with a new base class member. However, both ways to do it are defensible I think.


Another thing you have not shown is how the lookup itself proceeds. One has to be careful to not run into loops there.

There is another issue for lookups that is maybe less obvious:

struct S(ulong x){
    mixin(`enum has`~text(x)~`=2;`);
    auto get()(){ return S!(x+1)(); }
    alias get this;
}

void main(){
    S!0 s;
    writeln(s.has500);
    static assert(!is(typeof(s.has501)));
}

I.e., there may be an unbounded number of nested alias this. As you can see above, DMD seems to just limit the number of alias this expansions to 500. For multiple alias this, you probably also want to specify a reasonable search order, such that not too many irrelevant templates get instantiated just to find something at a low depth.

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.

On 1/17/2023 10:16 AM, 12345swordy wrote:
> We don't need alias this for classes, we just need custom implicit conversion for structs and classes. Other OOP languages have them, yet it from the cpp world that I keep hearing complaints regarding implicit conversions.

Implicit conversion is fine by itself. But consider the combinations of:

1. inheritance
2. alias this
3. overloading
4. implicit conversion
5. multiple inheritance
6. multiple alias this
7. integer promotion

(which all can be considered forms of implicit conversion) and it becomes incomprehensible.

It's not a question of "can we come up with a set of rules to make it all work". We certainly can. Whether the rules are predictable and intuitive rather than arbitrary and capricious is another matter entirely.

Case in point - C++ overloading rules. Last time I checked, they are two rather dense pages in the C++ Standard. I don't know anyone who can keep those rules in their head. I know I can't, and I implemented them correctly.

So how do people deal with it? This is what they tell me - they try random things until it works. They don't know why it works, and don't really care, they just move on.

This was one of the things that motivated me to move away from C++. D shouldn't be another C++. The overloading rules in D are much less complicated in C++ (because D uses the "least as specialized" rule), but still more complex than I'm comfortable with.

(The "least as specialized" rule is what C++ uses for template overloading, the C++ developers found a better way than the rats' nest of function overloading rules. I thought that would work better for function overloading, and indeed it does.)

If we go down the road of C++ complexity, we can't come back from it. We'll be stuck like C++ is stuck with function overloading.

Deciding what to leave out of a language is just as important as deciding what to put in. In fact, maybe it's *more* important.