DIP66 - Multiple alias this

[IgorStepanov via Digitalmars-d]

On Wednesday, 15 October 2014 at 03:49:41 UTC, Daniel N wrote:
> On Wednesday, 15 October 2014 at 02:46:05 UTC, Dicebot wrote:
>> On Tuesday, 14 October 2014 at 12:33:50 UTC, IgorStepanov 
>> wrote:
>>> This code tell that C is subtype of A and C is subtype of B.
>>> User can use this fact in his code:
>>> void foo(B);
>>>
>>> C c = new C;
>>> foo(c); //Ok.
>>> Of course, we shouldn't allow user to cast c to int:
>>> int i = c; //wrong
>>> However, user can explicitly cast c to his subtype, which is 
>>> convertable to int:
>>> int i = cast(B)c; //Ok
>>> Summarizing, I disagree with suggestion disallow this code at 
>>> type semantic stage.
>>
>> I agree. It will also make possible to break already working 
>> disambugation of `foo(c)` kind but adding new `alias this` to 
>> one of subtypes independently. That sounds annoying.
>
> I guess the best part of D is, you have the means to fix 
> anything you disagree with yourself... I can add a static 
> assert to my class and be happy.
>
> I have another idea, we could define that the shortest 
> conversion chain wins, analogous to type promotions, that makes 
> it possible to contain the issue inside C.
>
> class C
> {
>   A a;
>   B b;
>
>   int disambiguate_int()
>   {
>     return a;
>   }
>   alias a this;
>   alias b this;
>   alias disambiguate_int this;
>   static assert(__traits(compiles, {int _ = C.init;}), 
> "Ambiguous alias this");
> }
>
> i.e. this assert should pass.

In first edition I've implemented rule, when if type defines 
alias this directly, this alias hides all indirect aliases with 
the same type. However Andrey said that we should implement the 
strictest rules as possible and maybe relax them later.
Thus I implemented current rules, but saved the old implemetation 
of search. After some time we will able to return to first rule. 
It's not hard.