digitalmars.D.bugs - [Issue 6434] New: opDispatch must be considered before alias this.
- d-bugmail puremagic.com (31/31) Aug 03 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6434
- d-bugmail puremagic.com (11/11) Aug 15 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6434
- d-bugmail puremagic.com (29/29) Aug 16 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6434
- d-bugmail puremagic.com (20/20) Aug 16 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6434
- d-bugmail puremagic.com (10/52) Aug 16 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6434
- d-bugmail puremagic.com (12/12) Aug 25 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6434
- d-bugmail puremagic.com (10/10) Oct 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6434
- d-bugmail puremagic.com (32/32) Oct 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6434
- d-bugmail puremagic.com (10/10) Apr 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6434
- d-bugmail puremagic.com (18/18) Mar 06 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6434
http://d.puremagic.com/issues/show_bug.cgi?id=6434 Summary: opDispatch must be considered before alias this. Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: gor boloneum.com --- When a class or struct has an opDispatch and an alias this, the alias this is considered first and a member access gives "no such property" error: struct A { Variant i; alias i this; void opDispatch(string name)() { } } unittest { A a; a.weird; // no property 'weird' for type 'VariantN!(maxSize)' } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 03 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6434 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch, rejects-valid CC| |k.hara.pg gmail.com https://github.com/D-Programming-Language/dmd/pull/315 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 15 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6434 Max Samukha <samukha voliacable.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |samukha voliacable.com PDT --- I am not sure. opDispatch is meant to be a fallback mechanism used after all regular lookups fail. For example, one intended use of opDispatch is to dynamically handle calls to members unavailable statically. With "alias this" given the lowest priority, one would need to manually forward calls to inherited members: struct A { Variant i; alias i this; auto opDispatch(string name, A...)(auto ref A args) { static if (isCallableOnI!(name, A))) mixin("return i." ~ name ~ "(args);"); // this shouldn't be necessary else return dispatchDynamically(name, toVariants(args)); } } So the bug is in opDispatch not being considered after "alias this" lookup fails, and not in the order of lookups. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 16 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6434 PDT --- On the other hand, opDispatch considered first gives much more flexibility. Then, what to do with regular inheritance: class A { int foo(); } class B : A { void opDispatch(string name)() { } } auto b = new B; b.foo(); Should foo be opDispatched? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 16 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6434 --- I agree. This would make more sense. Let the opDispatch be used after alias this.I am not sure. opDispatch is meant to be a fallback mechanism used after all regular lookups fail. For example, one intended use of opDispatch is to dynamically handle calls to members unavailable statically. With "alias this" given the lowest priority, one would need to manually forward calls to inherited members: struct A { Variant i; alias i this; auto opDispatch(string name, A...)(auto ref A args) { static if (isCallableOnI!(name, A))) mixin("return i." ~ name ~ "(args);"); // this shouldn't be necessary else return dispatchDynamically(name, toVariants(args)); } } So the bug is in opDispatch not being considered after "alias this" lookup fails, and not in the order of lookups.I think all VISIBLE members should be used before opDispatch.On the other hand, opDispatch considered first gives much more flexibility. Then, what to do with regular inheritance: class A { int foo(); } class B : A { void opDispatch(string name)() { } } auto b = new B; b.foo(); Should foo be opDispatched?-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 16 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6434 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla digitalmars.com Resolution| |FIXED 17:38:45 PDT --- https://github.com/D-Programming-Language/dmd/commit/e3f1fa2d00250d8b94f6ae653c11856a1ea227c0 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 25 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6434 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pelle.mansson gmail.com *** Issue 4224 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6434 Reopened pull request. https://github.com/D-Programming-Language/dmd/pull/349 Points: 1. alias this lookup should be considered first. It is the synonym of super-class. 2. If alias this lookup fails, *most derived* opDispatch should be used. // From https://github.com/D-Programming-Language/dmd/pull/349#issuecomment-1923037 struct A { int opDispatch(string s)() { return 1; } } struct B { A a; alias a this; int opDispatch(string s)() if (s == "bsfunc") { return 2; } } void main() { B b; assert(b.bsfunc() == 2); assert(b.notfoundanywhere() == 1); // *1 } The most derived opDispatch from B is B.opDispatch, then b.xxx is always transformed to b.opDispatch!("xxx"). Therefore, line *1 doesn't compile, and A.opDispatch is never used. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6434 SomeDude <lovelydear mailmetrash.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lovelydear mailmetrash.com PDT --- The program in description now compiles and runs on 2.059 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 27 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6434 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |enhancement 23:25:22 PST --- I agree with Steven. opDispatch should be considered first. The rationale is straightforward - the wrapper gets to decide, not the wrappee, what opDispatch means. If the wrapper wants to forward to the alias this, it can do so with an appropriate implementation of opDispatch. But if alias this takes precedence, one is stuck. So, barring a more compelling rationale for alias this overriding, this enhancement should be rejected. I also marked this as an enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 06 2013