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