DIP66 - Multiple alias this

[Timon Gehr via Digitalmars-d]

On 10/10/2014 07:09 PM, IgorStepanov wrote:
> I've created DIP for my pull request.
> DIP: http://wiki.dlang.org/DIP66
> PR: https://github.com/D-Programming-Language/dmd/pull/3998
>
> Please, comment it.

- "C c;
int i = c; //Error: c.a.i vs c.b.i

static assert(is(C : int)); //Ok, because C is subtype of int anyway."

So now we can have 'subtypes' whose instances cannot be stored in 
variables of the 'base type'?

Such behaviour is inconsistent with both the reference implementation 
and the documentation (and the two happen to be mutually inconsistent on 
how 'is(:)' should behave as well. :o) )


- "The following pseudo-code illustrates this: [...] Finally, if 
resultSet contains only one candidate, the compiler will accept it."

This process might very well never terminate but it could terminate in 
more cases if it did something better than the naive brute-force search. 
I.e. either report cycles or don't keep exploring around cycles, but 
just looping indefinitely on cycles like the following is IMO not a good 
course of action:

struct S{
     alias get this;
     T get(){ return T.init; }
}
struct T{
     alias get this;
     S get(){ return S.init; }
     int x;
     alias x this;
}

void main(){
     S s;
     int x=s;
}

Furthermore, the following code compiles now, but doesn't under the 
approach described in the DIP. Is this an actual regression your pull 
introduces or is there a bug in the pseudocode?:

class A{
     alias x this;
     int x;
}

class B: A{
     alias y this;
     int y;
}

void main(){
     int x = new B();
}

The same issue also needs to be considered if A and B are structs 
instead and B has an additional alias this to an A (the solution might 
also be part of a fix for the cycle issue).

- "If resultSet contains more then one candidates, the compiler raises 
an error."

Why? The language already has a way to deal with cross-scope overload 
resolution. (Also, what makes candidates different?)