Short list with things to finish for D2

[Travis Boucher]

Rainer Deyke 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.
> 
> 

Passing op as the symbol allows for mixin("this.data"~op~"that.data;");

What I was hoping for was a catch-all for unknown non-operation methods, 
which could allow for dispatching to functions that are not even known 
at runtime (ie. trigger a lookup in a shared object, or pass along to a 
scripting language engine).