On Friday, 30 September 2016 at 09:55:36 UTC, pineapple wrote:
On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis wrote:
Except that it kind of is. It's an example of a language allowing you to mess with too much and make it so that it doesn't function as expected, which is what happens when you overload operators to act in a way inconsistent with how they work with the built-in types.

Let me see if I understand your argument: We can't make D more expressive because a language far more popular than D is so expressive it makes it possible to do unconventional things, if you are so inclined?
But operator overloading doesn't increase the language expressiveness. They provide nothing that you can't already do using ordinary function calls.
So forget expressiveness as an argument.
Operator overload is syntactic sugar, added to serve a single purpose: to allow mimic buildin types. So they should provide everything needed to do so, and nothing more. Adding more may be asked for, but this is not reasonable, because it is unrelated to the original purpose but increases only the possibilities to obfuscate the code by doing something misleading (there are already endless such possibilities, but that makes asking for more no more reasonable).

On Friday, 30 September 2016 at 19:09:25 UTC, Timon Gehr wrote:
On 30.09.2016 18:11, Jonathan M Davis via Digitalmars-d wrote:
Regardless, D already has a lot of powerful stuff in it, much of which will allow you to blow your foot off if you're really inclined to. The overloaded operators just so happened to be implemented in a way that doesn't let you blow your feet off as freely as C++'s overloaded operators will let you do.


OTOH, feet are useless if you are not allowed to walk (even if you choose not to blow them off).
You are allowed to walk. You can express everything that is possible with operator overloading in lots of other ways. And you can express everything that operator overloading was designed for with it - but maybe not everything beyond that. Use other ways to express such. If the compactness of expression written using operators is everything you are interested in - define some language and write a parser for it, and enjoy how short you can express everything you need with it. You can even write such stuff directly in your D code and let some string mixins massage it to compile.

I can't see the point to relax the rules for operator overloading unless you can show that they prevent parts of the original design goal.

PS: opCmp can return float, so the comparison can result in NaN (not conparable) - and as this is necessary to mimic some basic types (all floatingpoint types) removing this possibility would indeed prevent parts of the original design goal!

Reply via email to