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.
