DIP66 v1.1 (Multiple) alias this.

[Andrei Alexandrescu via Digitalmars-d]

On 11/2/14 6:55 AM, IgorStepanov wrote:
> http://wiki.dlang.org/DIP66
>
>> * "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 disagree with that. Current check is not recursive and prevent you
> code from a silly errors:
>
> struct X(T, V)
> {
>     T t;
>     V v;
>     alias t this;
>     alias v this; //Error if is(T == V). However this code is
> fundamentally broken, and this error should be raised as soon as possible.
> }

The code is not fundamentally broken if alias this is never used. I 
agree rejecting the code compulsively is also sensible, ONLY if there is 
a simple way to write a static if condition to make the code work. Meaning:

struct X(T, V)
{
     T t;
     V v;
     static if (please_fill_this)
         alias t this;
     static if (please_fill_this_too)
         alias v this;
}

If the two conditions are too hard to write then it would be difficult 
to argue this point successfully.

> class A : B
> {
>     B b;
>     alias b this; //Error: super type (B) always hides "aliasthised"
> type B because base classes should be processed before alias this types.
> }

That's fine to reject in all cases.

>> * 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.
>
> I agree with this suggestion, however it breaks an existing code.

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.

When alias this was introduced the decision of opDispatch vs. alias this 
was not deeply elaborated. In hindsight opDispatch should probably have 
come after because it's really a "method not found" catch-all whereas 
alias this is subtyping. That said, compelling arguments might come 
later the other direction. So making it an error for now would be 
sensible. It should only affect rather obscure code.

> opDispatch shouldn't come before base type lookup, because it will hide
> basic methods like toString.

Agreed.

> opDispatch may come after alias this lookup, however it will
> fundamentally change program behaviour.

Understood.

> Current (implemented is released compiler) behaviour:
[snip]

Understood. All: okay to make alias this + opDispach applicable to the 
same expression an error?

> And, TBH, this issue not relevant with multiple alias this :-)

Agreed. It is, however, good to revisit the decision and tighten that 
screw properly now that we have the opportunity.

>> * 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.
>
> Ok. I've removed pseudocode. Is it better now?

I'm flying now :o)... will take a look.

>> * IMPORTANT: The DIP must discuss rvalue vs. lvalue cases.
>
> Done. I've added corresponding chapter to the DIP and commit to the PR.

I'm sending this now with these points, will make one more pass through 
the DIP when I'm online again.


Andrei