I like syntactic extension. In some cases that includes operator overloading. I certainly wouldn't say all languages should have it - I mean, some languages don't even have *operators*. And if you do have operators, operator overloading still seems a bit ad hoc. I'd prefer a more principled approach, like Haskell's type classes (unless that's meant to be included under "operator overloading"). But if it's operator overloading or nothing, I'd certainly prefer it, personally.
I think it's true that operator overloading (probably any overloading, I guess) makes a language more complicated and code more "non-local". In some cases, that might justify excluding it, if the language designer is willing to accept more verbose code in exchange.
So, it seems that operator overloading just exposes some useful and intuitive function names. The creators of Google Go make an interesting argument against including it:
Go FAQ wrote:
[Operator overloading] seems more a convenience than an absolute requirement. Again, things are simpler without it.
And I'm not quite sure I get that argument. Just because it's not necessary doesn't mean it isn't useful, and if it's useful, I don't see why it shouldn't be included. I got into an argument with my dad about this and he says that he doesn't necessarily disagree with me, but I'm not really considering the other side's argument (which is so preposterous I'm not even going to consider that).
Are you saying the suggestion you should consider the other side is preposterous? Or that the other side in this case is preposterous on the face of it, so you're not going to consider it further?
Either way, I think that if smart people have an argument against your position, you should at least give it careful thought.
sourmilk wrote:The problem with C#-style properties is that they obscure whether you're doing a function call or simply referring to a variable, meaning that you could be doing an O(n!) operation without realizing you're even calling a function. That's not the worst thing in the world, particularly when you know the language has properties, but I kind of don't like it.
You realize this is the same sort of argument that can be made against operator overloading? I'm not saying it's inconsistent to call operator overloading one way and properties another, but I think the fact that you're taking the opposite position on an analogous issue should suggest that the question of operator overloading is not as black and white as you think it is.
EvanED wrote:To be honest, I've always thought this was a pretty BS argument. How would you index into a collection without operator overloading? Something like c.get(7). But .get has the same problem -- it could take foreever or make a database connection or whatever.
You could still index built-in types with . I think the point of the argument is that using operator overloading makes it look like indexing will have similar properties to that for built-in collections (which may not be the case), whereas some other method name would be less misleading. I tend to agree with Sc4Freak that the onus should be on the user of overloading to not break expectations.
Great Justice wrote:I think it's a necessity for bottom-up development. The system shouldn't treat your UDTs as some foreign, 3rd-rate constructs and its own as special.
I agree, but I think operator overloading is little more than a token effort in that direction. You should be able to define your *own* operators (preferably with arity, precedence and associativity).