www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6434] New: opDispatch must be considered before alias this.

reply d-bugmail puremagic.com writes:
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


--- Comment #0 from Gor Gyolchanyan <gor boloneum.com> 2011-08-03 06:14:26 PDT
---
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
next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #1 from Kenji Hara <k.hara.pg gmail.com> 2011-08-15 22:15:40 PDT ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6434


Max Samukha <samukha voliacable.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |samukha voliacable.com


--- Comment #2 from Max Samukha <samukha voliacable.com> 2011-08-16 02:39:02
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6434



--- Comment #3 from Max Samukha <samukha voliacable.com> 2011-08-16 03:07:32
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6434



--- Comment #4 from Gor Gyolchanyan <gor boloneum.com> 2011-08-16 03:55:33 PDT
---
I agree. This would make more sense. Let the opDispatch be used after alias
this.

(In reply to comment #2)

 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.

(In reply to comment #3)

 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #5 from Walter Bright <bugzilla digitalmars.com> 2011-08-25
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #7 from Kenji Hara <k.hara.pg gmail.com> 2011-10-23 22:20:39 PDT ---
*** 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6434



--- Comment #8 from Kenji Hara <k.hara.pg gmail.com> 2011-10-23 22:29:00 PDT ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6434


SomeDude <lovelydear mailmetrash.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lovelydear mailmetrash.com


--- Comment #10 from SomeDude <lovelydear mailmetrash.com> 2012-04-27 07:48:07
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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6434


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |enhancement


--- Comment #11 from Walter Bright <bugzilla digitalmars.com> 2013-03-06
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