Short list with things to finish for D2

[Andrei Alexandrescu]

Travis Boucher wrote:
> 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;");

Also it does not require remembering the correspondence between symbols 
and their names.

> 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).
> 

I agree. This is something very interesting.


Andrei