Overloading relational operators separately; thoughts?

[pineapple via Digitalmars-d]

On Saturday, 1 October 2016 at 07:13:39 UTC, Martin Nowak wrote:
> The fact that it's not possible to overload < but have to use 
> the ternary opCmp is even a performance problem. All std 
> algorithms only use less as a predicate, leading to lots of 
> unnecessary cycles when e.g. sorting UDTs.

On Saturday, 1 October 2016 at 11:53:07 UTC, Andrei Alexandrescu 
wrote:
> Apparently in dmd the generated code is less efficient: 
> https://goo.gl/OWxbA0. In gdc it's the same: 
> https://godbolt.org/g/NmUyXM. I couldn't test with ldc, 
> http://ldc.acomirei.ru seems down. -- Andrei

On Saturday, 1 October 2016 at 06:46:31 UTC, Russel Winder wrote:
> This debate is about whether D constrains people as Java does 
> or whether it enables people as C++ and Python do.
>
> Or use C++ or Python which allow for this. Fine, end of D 
> having a future amongst a large section of the programming 
> population. This is fine. Unless D wants to be a player in this 
> game.
>
> This has already been done, read the thread. SQLAlchemy. The 
> expression language is a a lovely builder DSL for constructing 
> SQL entirely in Python with no parser overhead. No operator 
> overloading, no DSL for builder languages. See same on the JVM: 
> in Java you can't do it, Kotlin, Ceylon, Scala, Groovy, do it 
> beautifully, and a lot of people do.

This isn't a PR yet because it's not nearly ready for general 
consumption, but these are all good points and I'd greatly 
appreciate if you would all please take a few minutes to express 
them in the DIP and get the changes merged so that we can have 
something that lays out clearly the pros and cons of this change.

https://github.com/pineapplemachine/DIPs/blob/operator_overload_expansion/DIPs/DIP1003.md