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

[IgorStepanov via Digitalmars-d]

On Tuesday, 31 March 2015 at 20:01:14 UTC, Andrei Alexandrescu 
wrote:
> 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

Ok, I've applied your changes to the DIP page, and I'm starting 
to rework my github PR. Sorry for the slow work (I'm very busy 
last time). However I still working. Stay on line=)