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

Reply via email to