Some problems with operator overloading

[Don]

bearophile wrote:
> 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).

The thing which needs to be emphasised, is:

opBinary() is just for numeric programmers.

opEquals() is for everyone.

Defining == for a user-defined type is an everyday feature. Defining / 
is a niche feature.

I think that once a person has realized that, they'll have no problems 
with knowing that they should not use opBinary.