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
