Overloading relational operators separately; thoughts?

[Dominikus Dittes Scherkl via Digitalmars-d]

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!