Overloading relational operators separately; thoughts?

[Timon Gehr via Digitalmars-d]

On 30.09.2016 23:43, Dominikus Dittes Scherkl wrote:
> 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.

Please don't do this; it destroys threading.

>
> 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.

There's a continuum here. Another data point:
https://www.youtube.com/watch?v=IqhlQfXUk7w

(Though here, one seems to require a good set of feet.)

> You can express everything that is possible
> with operator overloading in lots of other ways.

Everybody knows this. And everyone in the above video is getting where 
they are going.

> And you can express
> everything that operator overloading was designed for with it

Hopefully. My qualm is with the design. (It is not that significant, 
it's basically in the "fly that sits on your face at an irregular 
frequency" corner.)

> - 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

Am not. You might be confusing me with someone else. But don't assume 
I'm going to accept huge overhead, because this does destroy the point 
of the original exercise at some point.

> - define some language

Yes, I can design my own programming language. However, I don't 
currently have the resources to create the perfect tool for every job I 
face.

> and write a parser for it,

Sure, I also have a parser. Now what? It does not integrate nicely with 
D code.

> and enjoy how short you can express everything you need with it.

Conciseness never hurts. I'm interested in using notation that is 
similar to the one I use on paper and in scientific publications. It's 
also about ensuring correctness by making it easy to understand at a 
glance what is written down (by e.g. a domain expert). This is 
understood to have certain limitations (e.g. there's no built-in 
integral operator), but the notation that does exist corresponds 
precisely -- there is no misusing of names anywhere.


> You can even write such stuff directly in your D code and let some
> string mixins massage it to compile.
> ...

This does not scale. (It works for some things, not others.)

> 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.
> ...

Then I'm not interested in trying to convince you because you can always 
just claim that the use case I present was not part of the original 
design goal (which is not written down formally anywhere).

> 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!

I know. I believe I was even the first one to point this out on the NG. 
It was an accident, not designed. The cause was lack of some pointless 
restriction.