[Issue 5893] New: Allow simple aliases for operator overloading

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Apr 26 13:08:22 PDT 2011


http://d.puremagic.com/issues/show_bug.cgi?id=5893

           Summary: Allow simple aliases for operator overloading
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: schveiguy at yahoo.com


--- Comment #0 from Steven Schveighoffer <schveiguy at yahoo.com> 2011-04-26 13:04:35 PDT ---
If you wish to use virtual operators in D classes, the current thinking is you
would wrap a virtual function with a template function that handles the
operator.  This means you have to implement a template function, taking care to
use the same arguments that the other function will require, and using the
proper return type as well.

I thought of an alternative way to do this that makes wrapping virtual
functions super-easy.  However, the compiler rejects it (for a strange reason).

class C
{
   void concatAssign(C other) { }
   void concatAssign(int other) { } // to demonstrate overloading

   template opOpAssign(string s) if (s == "~=")  // line 6
   { alias concatAssign opOpAssign; }
}

void main()
{
   auto c = new C;
   c.opOpAssign!"~="(c); // works
   c.opOpAssign!"~="(1); // works
   c ~= 1; // line 15
}

testaliasvirt.d(6): Error: template testaliasvirt.C.opOpAssign(string s) if (s
== "~=") is not a function template
testaliasvirt.d(15): Error: cannot append type int to type testaliasvirt.C

I think the compiler should accept this code.  In fact, I thought the compiler
just rewrote ~= to .opOpAssign!"~=".  The error message seems to suggest it
does some unnecessary checking to make sure it's a function template.

If it did work, this method provides not only a very efficient and backwards
compatible way to do operators (no wrapper code is generated/called, no relying
on inlining to make sure performance isn't hurt), but one could easily create a
single mixin that forwarded all operators to the old style operators (if you
didn't want to do it manually like I have).  You don't even need to deal with
forwarding parameters (the biggest pain of auto-wrapping functions)!

I can see this being of use for opDispatch as well.

Note that bug 4182 would have to be fixed for true backward compatibility (i.e.
forwarding covariance with the virtual operators).  But that technically is a
separate issue, not a blocker.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list