On 09/11/2015 09:40 PM, Martin Nowak wrote:
I find the reasons for turining down my ER a bit moot. ...
+1.
[Issue 14593 – operator overloading can't be used with expression templates](https://issues.dlang.org/show_bug.cgi?id=14593) AFAIK expression templates are the primary choice tom implement SIMD and matrix libraries.
OTOH, they are a hack.
And I still have [this idea](http://dpaste.dzfl.pl/cd375ac594cf) of implementing a nice query language for ORMs. D currently doesn't allow to override some operators like < <= > >= && || !=. At least the comparison operators are really limiting, e.g. it's not possible to efficiently implement logical indexing. vec[vec < 15], vec[vec == 15], vec[(vec != 15) & (vec > 10)] Also opCmp is less efficient to implement than opBinary!"<" for many types. Generally any good implementation of an algorithm should only require a less operator, not a full ordering opCmp. ...
The rewrite a < b => a.opCmp(b)<0 is usually wasteful, but both methods can be the most efficient choice depending on the application. Two calls to opBinary!"<" will usually not be more efficient than one call to "opCmp".
I.e. the precedence should be the other way: try a.opBinary!"<"(b) first and then fall back to a.opCmp(b)<0. (Maybe it would also make sense to automatically provide opCmp if missing when opBinary!"<" has been implemented, such that generic code can use opCmp for all comparable types. Built-in comparable types should also provide opCmp.)
The short circuit operators && and || have a special semantic and can't be easily, but there is & and | so it's not really required. ...
There's the 'lazy' keyword.
... Does anyone have a different idea how to make a nice query language? db.get!Person.where!(p => p.age > 21 && p.name == "Peter")
You could give up on operator syntax.
