Short list with things to finish for D2

[grauzone]

Andrei Alexandrescu wrote:
> Any more thoughts, please let them known. Again, this is the ideal time 
> to contribute. But "meh, it's a hack" is difficult to discuss.

Well that's just like as if Bjarne Stroustrup would ask you: "What would 
you have done in my place? This looked like the right thing to do at 
this time!". And now we're working on a language that's supposed to 
replace C++.

Partially I don't really know how opBinary is supposed to solve most 
operator overloading problems (listed in DIP7). It just looks like a 
stupid dispatch mechanism. It could be implemented by using CTFE and 
mixins without compiler changes: just let a CTFE function generate a 
dispatcher function for each opSomething to opBinary. Of course, if you 
think operators are something that's forwarded to something else, it'd 
be nicer if dmd would be doing this, because code gets shorter. So 
opSomething gets ditched in favor of opBinary. But actually, the 
functionality of opBinary can be provided as a template mixin or a CTFE 
function in Phobos. At least then the user has a choice what to use.

(About the issue that you need to remember names for operator symbols: 
you know C++ has a fabulous idea how to get around this...)

Now what about unary operators? Or very specific stuff like opApply? 
What's with opSomethingAssign (or "expr1[expr2] @= expr3" in general)? 
opBinary doesn't seem to solve any of those. Also, all this just goes 
down to a generic "opOperator(char[] expression, T...)(T args)", where 
expression is actually an expression involved with the object. It feels 
like this leads to nothing. And opBinary is a just a quite arbitrary 
stop on that way to nothing. Just a hack to make code shorter for some 
use cases.

One way of solving this issue about "extended operator overloading" 
would be to introduce proper AST macros. An AST macro could match on a 
leaf of an expression and replace it by custom code, and use this 
mechanism to deal with stuff like "expr1[expr2] @= expr3" (and I don't 
see how opBinary would solve this... encode the expression as a string? 
fallback to naive code if opBinary fails to match?). At least that's 
what I thought AST macros would be capable to do.

Anyway, AST macros got ditched in favor of const/immutable, so that's 
not an option. You also might feel about AST macros as a vague idea, 
that only solves "everything" because it's so vague and unspecified. 
Feel free to go on about this.