DIP66 1.2 (Multiple) alias this. Continuation of work.

[Andrei Alexandrescu via Digitalmars-d]

On 3/31/15 7:28 AM, IgorStepanov wrote:
> On Monday, 30 March 2015 at 18:33:17 UTC, Andrei Alexandrescu wrote:
>> On 3/30/15 8:04 AM, Steven Schveighoffer wrote:
>>> On 3/29/15 1:34 PM, IgorStepanov wrote:
>>>
>>>> 1. We should reject types which use opDispatch and alias this at the
>>>> same time.
>>>
>>> Why? Alias this has no filter. opDispatch can use template constraints.
>>> It makes perfect sense to prefer opDispatch, unless it doesn't have a
>>> valid match, and then use alias this instead.
>>>
>>> For example, if I wanted to wrap a type so I can instrument calls to
>>> 'foo', I could do something like this:
>>>
>>> struct FooWrapper(T)
>>> {
>>>    T t;
>>>    alias t this;
>>>    auto opDispatch(string s, A...)(A args) if(s == "foo") {
>>> writeln("calling foo"); return t.foo(args); }
>>> }
>>>
>>> Why is this a bad use case?
>>
>> The idea is to start restrictive and define interaction meaningfully
>> later based on compelling use cases. -- Andrei
>
> Andrei, do you approve those changes? Can we move to work on my github PR?

I made a few editorial passes, no major changes. I think there's still a 
fly in the ointment. The resolution algorithm goes:

1. If xyz is a symbol (member, method, enum etc) defined inside 
typeof(obj) then lookup is done.
2. Otherwise, if xyz is a symbol introduced in the base class (where 
applicable), then lookup is done.
3. Otherwise, if opDispatch!"xyz" exists, then lookup is done.
4. Otherwise, alias this is attempted transitively, and if xyz is found, 
then lookup is done.
5. Otherwise an UFCS rewrite is effected.

This puts opDispatch in between inheritance and subtyping, which I think 
we discussed is inappropriate - alias this should be effectively subtyping.

If we're really convinced alias this means multiple subtyping, the 
inherited type should not have a special role. However, it simplifies a 
lot of things to give one particular subtype a leg up on all others. So 
I think this would work:

1. If xyz is a symbol (member, method, enum etc) defined inside 
typeof(obj) then lookup is done.
2. Otherwise, if xyz is a symbol introduced in the base class (where 
applicable), then lookup is done.
3. Otherwise, if xyz is found at least via either an opDispatch!"xyz" or 
alias this conversion, then lookup is done.
4. Otherwise an UFCS rewrite is effected.

Then you explain that if you find more than one possibility via 
opDispatch and alias this, that's an ambiguity error.

I noticed you do mention in the Limitations section that opDispatch and 
alias this cannot be simultaneously present, but that kind of 
contradicts your resolution algorithm.


Andrei