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
