Some problems with operator overloading

[Steven Schveighoffer]

On Tue, 16 Mar 2010 14:03:37 -0400, bearophile <bearophileHUGS at lycos.com>  
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.

Is this the reason?  I'm actually curious why opEquals cannot be  
assimilated into opBinary.

> 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("==")).

I've seen plenty of incorrect-name bugs from newbies with the old operator  
system.  I don't think the new system is any more bug prone, it will just  
take time to get used to (as did the old system).

>> 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.

Then what you are asking for does not help much.  Essentially, the best  
test for the compiler to run is trying to compile opBinary!("=="), and if  
it does throw an error.  If this is not how it is done, then it's some  
kind of half-ass check, which can leave lots of room to still mess up.  I  
can think of at least three different ways to write opBinary so  
opBinary!("==") compiles.

But I'd rather not have the compiler impose such restrictions.  It  
complicates the compiler, and gives opBinary a half-keyword status when it  
is simply a symbol right now.

> 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.

I disagree.  I think people will learn the right way and just start doing  
it that way.  It remains to be seen, but I think changing things now is  
too much of a knee-jerk reaction.  We've had a total of one release with  
the new operator system!

-Steve