On Wed, 18 Nov 2009 23:33:54 -0500, Andrei Alexandrescu
<seewebsiteforem...@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.