Short list with things to finish for D2

[Robert Jacques]

On Wed, 18 Nov 2009 23:33:54 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Leandro Lucarella wrote:
>> grauzone, el 19 de noviembre a las 03:47 me escribiste:
>>> Does the current proposal make things simpler at all? All you're
>>> doing is to enable the programmer to "fix" the clumsy semantics by
>>> throwing lots of CTFE onto the problem. Why not generate the
>>> operator functions with CTFE in the first place...
>>  I was about to say that, the solution is a hack. I could understand a  
>> hack
>> if there were no other way to do it, but you can generate the code for  
>> the
>> opXxx using CTFE/string mixins already: we already have a hackish
>> solution. I don't think adding a new hack would be nice (specially when  
>> it
>> will be a big change).
>>  Maybe a not-so-hackish solution can be found when AST macros get
>> implemented.
>
> 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.
>
> I'd be grateful if you argued your point further and hopefully suggested  
> an approach that is better. I want us to move fast with this. So it's  
> just the right time to contribute.
>
>
> Andrei

For what it's worth, I used aliases of a template binary op function in  
order to do all the operator overloads of a small vec class. So I like  
your solution.