Some problems with operator overloading

[bearophile]

Steven Schveighoffer:

Thank you for this post, that gives me a chance to talk about this topic.

>What I meant was, opEquals could forward to opBinary, but if it's disallowed by the compiler, then that's not possible.<
>I just think it's overkill to restrict what functions are valid arbitrarily.<

In D I think == is a special case because for classes it does more complex things that are special for this case.

Constraints that are useful to prevent wrong code, like for example the type system, often forbid few cases of correct code. So when you design the constraints you must find a balance point in the middle.

I've written two little (< 500 lines) programs using the new operator overloading, and I have found that /(even using the online docs, it's easy to write wrong code (and currently those operators have about 8-10 bugs, found by other people and me). The templates can be badly written, you can use the wrong names, the strings can be the wrong ones or even wrongly written, you can miss necessary operators, or even you can miss a corner case (== is a binary op, but it has its own method name, so it's a special case. The first time I have indeed used opBinary("==")).

You have to understand that the new operators are quite more bug-prone compared to the old ones, the operator strings introduce new possible ways to write bugs, that were not possible with the older system (and even with the old operator overloading system it was not that hard to put bugs in the code).

So I think that it's better to have a front-end that helps me catch many possible operator overloading bugs. Otherwise you probably will see many bugs in that kind of code :-)


> Also, if you defined opBinary like this:
> auto opBinary(string op)(const ref T rhs) {...}
> Then should the compiler disallow this?  opBinary!("==") will compile.  

I don't ask the compiler to become magic and avoid any possible bug. I want the compiler to do what's possible to help me avoid bugs when I use the new operator overloading.

To avoid the need of a magic compiler then some convention can be adopted, and the compiler can raise the syntax error when the programmer doesn't follow the convention. This puts constraints, but they are good ones. I surely do not want full freedom when I add operators to a struct/class, I want a compiler that allows me to do only sane things, even if forbids me to do few possible things. I don't want to program Perl with a static type system :-) D wants to be a safer language.

So some way has to be invented to avoid that kind of bugs, and if that's not possible, then the design of the operator overloading has to be fixed.

Bye,
bearophile