DIP66 v1.1 (Multiple) alias this.

[Andrei Alexandrescu via Digitalmars-d]

On 11/2/14 6:57 AM, IgorStepanov wrote:
> And there is dispute about is expression: see
> http://forum.dlang.org/thread/ubafmwvxwtolhmnxbrsf@forum.dlang.org?page=5

OK, time to get this approved.

First, the current DIP doesn't seem to address this:

> Walter and I would agree to making the presence of BOTH alias this
> and opDispatch a compile-time error. That would break existing code
> but not change semantics silently.

Any thoughts on this? Currently opDispatch gets priority over alias 
this, see lookup step 3 in section "Semantics" of 
http://wiki.dlang.org/DIP66. That's problematic because it puts 
opDispatch in _between_ "normal" subtyping via inheritance and alias 
this, which is supposed to be just as solid as inheritance.

I think the principled solution is to combine steps 2 and 4 into step 2, 
i.e. alias this is as strong as inheritance. Any ambiguous symbols would 
be rejected.

The second possibility, less principled but probably practical, would be 
to swap steps 3 and 4. That way alias this has juuust a teensy bit a 
lower status than regular inheritance.

The simplest thing (which Walter favors) is to make the presence of both 
opDispatch and alias this a compile-time error. That would break only a 
teensy amount of code if any, and would give us time to investigate the 
best approach when compelling use cases come about. So I suggest we move 
forward with that for this DIP.

Regarding the is-expression controversy in 
http://forum.dlang.org/thread/ubafmwvxwtolhmnxbrsf@forum.dlang.org?page=5:

First off, is(S : T) is a subtyping test - is S a non-proper subtype of 
T, or not? (Non-proper or improper subtyping: S is allowed to be 
identical to T). "alias this" is a mechanism that introduces subtyping. 
It follows that subtyping introduced via "alias this" must be detected 
with is-expressions.

Now, you give an example of subtyping where one or more two objects of 
the same supertype may be reached through two or more different paths. 
This is a well-known problem in subtyping (known as diamond hierarchy or 
repeated inheritance).

In the case of "alias this", different objects of the same type may be 
reachable (or at least the compiler is unable to tell statically whether 
the objects are distinct or not). A correct but hamfisted solution would 
be to sever the subtyping relationship whenever the same type is 
reachable through multiple paths.

The versatility of "alias this", however, suggests a better solution: if 
T is indirectly reachable as a supertype of S through more than one path 
and the subtyping is either tested (by means of an is-expression) or 
effected (by means of an implicit conversion), the compiler should issue 
a compile-time error asking the user to define an "alias this" DIRECTLY 
inside S, which takes precedence over indirect reachability and informs 
the type system which T of the several reachable ones is needed.

Please let me know of any thoughts. Thanks!


Andrei