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

[Andrei Alexandrescu via Digitalmars-d]

On 3/31/15 1:20 PM, Steven Schveighoffer wrote:
> On 3/31/15 4:01 PM, 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.
>
> swap 2 and 3.

That would break code and again it's contradicted by restrictions 
mentioned below. No need to make the DIP overly complicated.

>> This puts opDispatch in between inheritance and subtyping, which I think
>> we discussed is inappropriate - alias this should be effectively
>> subtyping.
>
> I don't understand this statement. What is the difference between
> inheritance and subtyping?

Inheritance is only one of the forms of subtyping.

> To me, opDispatch is equivalent to adding a member function (with
> specific members overriding opDispatch), alias this is equivalent to
> inheriting from another type (with inherited members overriding alias
> this).
>
> And I still think that alias this + opDispatch conflicts should defer to
> opDispatch. It makes no sense to do it any other way.

Again: start conservative, loose screws later. No regrets.


Andrei