On Monday, 30 March 2015 at 15:04:20 UTC, 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?
>
> -Steve

You can split this code to two structs:

struct FooWrapper(T)
{
   struct FooDispatcher
   {
       auto opDispatch(string s, A...)(A args) {
           writeln("calling ", s);
       }
   }
   FooDispatcher d;
   T t;
   alias t this;
   auto foo(string s, A...)(A args)
   {
      writeln("calling foo"); return t.foo(args);
   }
}

FooWrapper!X x;
x.foo(1, 2); //FooWrapper.foo has been called
x.bar(1, 2); //FooWrapper.d.opDispatch has been called
X orig = x; //FooWrepper.t is returned.

===============
Yes, this code is much more tricky, but it work as you wish.
opDispatch + alias this may deliver many problems, if one of those has more high priority then the other.
We want to implement alias this maximally strictly, and after that, try to find rules which may be safely relaxed.

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?

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?

Gotta run for a couple hours, will review this shortly after. -- Andrei

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

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.

> 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?

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.

-Steve

On Sunday, 29 March 2015 at 17:34:21 UTC, IgorStepanov wrote:
> 3. is(T: B) should raise an error if there are many ways to convert T to B.

I think this will cause future problems. How hard would it be to include at type algebra system? (being able to use &, |, etc on types... sort of Venn diagram'ish.

Also, is(T:B) should reflect what it means. Just because a dog can be classed many ways doesn't mean it's not a dog.

I realize that this makes things harder but is(T:B) raising an error if there are more than one conversion path just seems wrong. isonly(T:B) or whatever makes visual sense would be a better option IMO.

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

On 2015-03-31 22:01, Andrei Alexandrescu wrote:

> 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.

Should opDispatch or "alias this" ever be looked up in the base class?

-- 
/Jacob Carlborg

On 3/30/15 3:19 PM, IgorStepanov wrote:
> On Monday, 30 March 2015 at 15:04:20 UTC, 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?
>>
>> -Steve
>
> You can split this code to two structs:
>
> struct FooWrapper(T)
> {
>     struct FooDispatcher
>     {
>         auto opDispatch(string s, A...)(A args) {
>             writeln("calling ", s);
>         }
>     }
>     FooDispatcher d;
>     T t;
>     alias t this;
>     auto foo(string s, A...)(A args)
>     {
>        writeln("calling foo"); return t.foo(args);
>     }
> }
>
> FooWrapper!X x;
> x.foo(1, 2); //FooWrapper.foo has been called
> x.bar(1, 2); //FooWrapper.d.opDispatch has been called
> X orig = x; //FooWrepper.t is returned.
>
> ===============
> Yes, this code is much more tricky, but it work as you wish.
> opDispatch + alias this may deliver many problems, if one of those has
> more high priority then the other.
> We want to implement alias this maximally strictly, and after that, try
> to find rules which may be safely relaxed.

Not exactly. Yes, you have successfully pointed out that using opDispatch to define one named method is sort of useless, but that was not my point. Imagine if you wanted to do that to all methods that were in a list. I can imagine a use case that logs all calls to a type that are defined by a list:

struct LogWrapper(T, string[] funcnames) { ... }

It is impossible to do this generically and also use alias this. In today's situation, I can't override *selected* pieces of alias this, I must override all of them, because opDispatch takes precedence, even if there is no overriding. For example, this doesn't work:

struct Wrapper(T)
{
   T t;
   alias t this;
   auto opDispatch(string name, A...)(A args) if(name == "foo")
   {
      mixin("return t." ~ name ~ "(args);");
   }
}

Call w.bar(), and even if T has a bar method, it fails to compile, because opDispatch *fully* eclipses alias this. Even fields cannot be accessed. However, alias this does still provide subtyping, I can call func(T t) with a Wrapper!T. This working aspect of alias this + opDispatch will break after your changes (though I'm not sure if this is a huge problem).

The reason to have opDispatch override alias this is because of the level of control in what to override. alias this does not allow fine grained overriding of certain pieces, it's all or nothing. In other words, with alias this having precedence, opDispatch becomes neutered. With opDispatch having precedence, one can select the pieces to allow to trickle through to alias this.

To me, because opDispatch is implemented in the most derived type, and because you can limit its effect, it should have total precedence over everything except other defined members in that derived type. It's a question of who is in charge of this derived type's API. opDispatch is a way to avoid boilerplating a ton of stuff. But the result of opDispatch should be considered first-class members.

And let us not kid ourselves. If we define an ordering for precedence here, it is not going to be changed in the future. Broken code will preclude that possibility. "Loosening the screws" does not mean "change the complete ordering of the feature."

-Steve

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=)