http://wiki.dlang.org/DIP66

First I want to apologize for the long absence.
I was very busy for those months and now I ready to continue the work.

This DIP has been approved with three clarifications:
about is-expression, about opDispatch and about "common" inheritance.
I've reflected those clarifications in this DIP version, and if it is OK, I'll start adaptation of my github PR to this DIP.

On Saturday, 28 March 2015 at 19:52:15 UTC, IgorStepanov wrote:
> http://wiki.dlang.org/DIP66
>
> First I want to apologize for the long absence.
> I was very busy for those months and now I ready to continue the work.
>
> This DIP has been approved with three clarifications:
> about is-expression, about opDispatch and about "common" inheritance.
> I've reflected those clarifications in this DIP version, and if it is OK, I'll start adaptation of my github PR to this DIP.

You're awesome, Igor. Thanks for taking on hard problems.

On Saturday, 28 March 2015 at 19:52:15 UTC, IgorStepanov wrote:
> http://wiki.dlang.org/DIP66
>
> First I want to apologize for the long absence.
> I was very busy for those months and now I ready to continue the work.
>
> This DIP has been approved with three clarifications:
> about is-expression, about opDispatch and about "common" inheritance.
> I've reflected those clarifications in this DIP version, and if it is OK, I'll start adaptation of my github PR to this DIP.

Can you explain the change from current situation a bit ?

On Sunday, 29 March 2015 at 08:03:37 UTC, deadalnix wrote:
> On Saturday, 28 March 2015 at 19:52:15 UTC, IgorStepanov wrote:
>> http://wiki.dlang.org/DIP66
>>
>> First I want to apologize for the long absence.
>> I was very busy for those months and now I ready to continue the work.
>>
>> This DIP has been approved with three clarifications:
>> about is-expression, about opDispatch and about "common" inheritance.
>> I've reflected those clarifications in this DIP version, and if it is OK, I'll start adaptation of my github PR to this DIP.
>
> Can you explain the change from current situation a bit ?

Do you mean "changes from previous DIP version"?
I've added three ideas to this version:
1. We should reject types which use opDispatch and alias this at the same time.
2. We want to semantic alias this at the same time as an inheritance (and disallow hidding of "alias this"-ed members by inherited members), but we shouldn't do this change now, because it may break a lot of existing code.
3. is(T: B) should raise an error if there are many ways to convert T to B.

If you ask about changes from current alias this implementation, this DIP introduces multiple alias this, and formally discribes different cases.

On Sunday, 29 March 2015 at 17:34:21 UTC, IgorStepanov wrote:
> Do you mean "changes from previous DIP version"?
> I've added three ideas to this version:
> 1. We should reject types which use opDispatch and alias this at the same time.

That sound overly imitative, but I can roll with that :)

> 2. We want to semantic alias this at the same time as an inheritance (and disallow hidding of "alias this"-ed members by inherited members), but we shouldn't do this change now, because it may break a lot of existing code.

I struggled with defining that one, so that is a good thing.

> 3. is(T: B) should raise an error if there are many ways to convert T to B.
>

SDC already reject alias if there are various path that lead to the same type.

On Sunday, 29 March 2015 at 17:34:21 UTC, IgorStepanov wrote:
> On Sunday, 29 March 2015 at 08:03:37 UTC, deadalnix wrote:
>> On Saturday, 28 March 2015 at 19:52:15 UTC, IgorStepanov wrote:
>>> http://wiki.dlang.org/DIP66
>>>
>>> First I want to apologize for the long absence.
>>> I was very busy for those months and now I ready to continue the work.
>>>
>>> This DIP has been approved with three clarifications:
>>> about is-expression, about opDispatch and about "common" inheritance.
>>> I've reflected those clarifications in this DIP version, and if it is OK, I'll start adaptation of my github PR to this DIP.
>>
>> Can you explain the change from current situation a bit ?
>
> Do you mean "changes from previous DIP version"?
> I've added three ideas to this version:
> 1. We should reject types which use opDispatch and alias this at the same time.

thats ok - I can use multiple alias this then to delegate to types that use opDispatch, right ? :P

> 2. We want to semantic alias this at the same time as an inheritance (and disallow hidding of "alias this"-ed members by inherited members), but we shouldn't do this change now, because it may break a lot of existing code.
> 3. is(T: B) should raise an error if there are many ways to convert T to B.
>
> If you ask about changes from current alias this implementation, this DIP introduces multiple alias this, and formally discribes different cases.

On 2015-03-29 19:34, IgorStepanov wrote:

> 1. We should reject types which use opDispatch and alias this at the
> same time.

Isn't there a well defined order these features apply in?

-- 
/Jacob Carlborg

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

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

On 3/30/15 2:33 PM, 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
>

Something tells me you don't think this is compelling. I do.

Any kind of wrapper type that intends to override some category of behavior is going to want to do this. Currently, we are stuck with opDispatch-ing all members, including fields.

It is also currently valid to use alias this solely as a cast, and use opDispatch to define the API. Outlawing these being used together would break any code relying on that.

BTW, if there is a clear and obvious way to define this, why are we willfully ignoring it? What is the downside of my use case?

-Steve