Short list with things to finish for D2

[Bill Baxter]

On Wed, Nov 18, 2009 at 10:55 PM, Rainer Deyke <rainerd at eldwood.com> wrote:
> Andrei Alexandrescu wrote:
>> I am thinking that representing operators by their exact token
>> representation is a principled approach because it allows for
>> unambiguous mapping, testing with if and static if, and also allows
>> saving source code by using only one string mixin. It would take more
>> than just a statement that it's hackish to convince me it's hackish. I
>> currently don't see the hackishness of the approach, and I consider it a
>> vast improvement over the current state of affairs.
>
> Isn't opBinary just a reduced-functionality version of opUnknownMethod
> (or whatever that is/was going to be called)?
>
> T opBinary(string op)(T rhs) {
>    static if (op == "+") return data + rhs.data;
>    else static if (op == "-") return data - rhs.data;
>    ...
>    else static assert(0, "Operator "~op~" not implemented");
> }
>
> T opUnknownMethod(string op)(T rhs) {
>    static if (op == "opAdd") return data + rhs.data;
>    else static if (op == "opSub") return data - rhs.data;
>    ...
>    else static assert(0, "Method "~op~" not implemented");
> }
>
> I'd much rather have opUnknownMethod than opBinary.  If if I have
> opUnknownMethod, then opBinary becomes redundant.

opBinary doesn't really become redundant because you still need the _r variants.
You could come up with some convention for the string that represents
the _r flavor of opUnknownMethod!("-") but why not just make'em
different methods?
I don't think there's enough in common between a typical operator and
a generic unknownMethod to make fusing them worth it.

--bb