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

[Steven Schveighoffer via Digitalmars-d]

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