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
