DIP66 - Multiple alias this

[IgorStepanov via Digitalmars-d]

On Tuesday, 28 October 2014 at 19:45:09 UTC, Andrei Alexandrescu 
wrote:
> On 10/10/14 10:09 AM, 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.
>
> Here's my destruction:
>
> * "symbol can be a field or a get-property (method annotated 
> with @property and taking zero parameters)." -> actually:
>
> (a) the @property annotation is not necessary
> (b) there may be one ore more parameters so long as they're all 
> defaulted
>
> So the text should be "obj.symbol must be a valid expression".
>
> * "At the AliasThis declaration semantic stage, the compiler 
> can perform the initial checks and reject the obviously 
> incorrect AliasThis declarations." -> it might be simpler (for 
> the sake of simplifying generic code) to just delay all error 
> checking to the first use.
>
> * I don't think the pseudocode helps a lot. Better let's have a 
> clear and precise specification (I've edited the lookup order 
> into an ordered list).
>
> * Regarding the lookup, opDispatch shouldn't come before alias 
> this, or should come before base class lookup. Essentially 
> alias this is subtyping so it should enjoy similar privileges 
> to base classes. A different way to look at it is opDispatch is 
> a "last resort" lookup mechanism, just one step above the UFCS 
> lowering.
>
> * The DIP should specify the working of alias this as 
> rewrites/lowerings, not pseudocode. Basically for each kth 
> declaration "alias symbolk this;" the compiler rewrites 
> "obj.xyz" as "obj.symbolk.xyz" and then does the usual lookup 
> on that expression. That means the whole algorithms is applied 
> again etc. If more than one rewrite typechecks, that's an 
> ambiguity error.
>
> * IMPORTANT: The DIP must discuss rvalue vs. lvalue cases. The 
> rewrite approach simplifies that discussion because it's clear 
> what happens by simply reasoning about the rewritten 
> expression. Lvalue vs. rvalue matters a lot practically. 
> Consider:
>
> struct A
> {
>     private int x;
>     alias x this;
> }
>
> struct B
> {
>     private int _x;
>     int x() { return x; }
>     alias x this;
> }
>
> Then x can be passed by reference, modified directly etc. for A 
> but not for B.
>
> ===========
>
> Congratulations on taking this to a DIP. It clarifies things 
> really nice and it's an example to follow for future language 
> changes.
>
>
> Andrei

Thanks for answer, I hope, I'll able to to carefully consider 
your comments tomorrow.

Now I want to ask about the one thing.
What do you think about compatibility with existing alias this 
implementation?

For example you wrote: "Regarding the lookup, opDispatch 
shouldn't come before alias this, or should come before base 
class lookup.".
This requirement breaks the existing code.
We can apply this change in DIP, however if we want to apply this 
change to compiler, we should be careful. Moreover, I don't see 
the way to create deprecation path: old 
implementation->deprecated old implementation & new 
inmplementation -> prohibited old implementation & new 
inmplementation.

If we will change the semantic order of proprerty resolving, we 
will not able to warn user about changes. Suddenly his code will 
be compiled in a different way.

And please comment my way to resolving "is" expression via 
alias-this:
http://forum.dlang.org/thread/ubafmwvxwtolhmnxbrsf@forum.dlang.org?page=5

Thanks for the DIP review.