On Tue, 16 Mar 2010 14:03:37 -0400, bearophile <bearophileh...@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
