On 09/13/2015 05:03 AM, Andrei Alexandrescu wrote: > Yah, understood. Problem here is the approach is bound to run into walls > at every few steps. Say you fix the comparisons to work. Then you have > operators such as LIKE that are necessary yet not representable in D. So > more tricks are in order. This is what I've seen with ET in C++ - an > endless collection of tricks to achieve modest outcomes at enormous costs.
But this is not an argument to rule out `opBinary!"<"`. To summarize the arguments. - logical indexing x[x < 20] e.g. opBinary!"<" returns a bit mask to select entries of a large vector - faster comparison struct Foo { size_t id; int opCmp(Foo rhs) { if (id < rhs.id) return -1; if (id == rhs.id) return 0; else return 1; } bool opBinary(string s:"<")(Foo rhs) { return id < rhs.id; } } Sorting a million Foos w/ random ids is 37.5% slower with opCmp. foos.sort!((a, b) => a.opBinary!"<"(b))(); // 104ms foos.sort!((a, b) => a < b)(); // 143ms - expression templates I'm well aware of the limitations, but still think it will work out nicely for an ORM b/c there is precedence in other language, e.g. Rails' (ActiveRecord) query syntax. - language regularization It's surprising to find these "arbitrary" language limitations. The non-predictability of what's possible has always been a huge issue for me with C++, i.e. you come up with an idea, spend 4 hours implementing it only to find out that the small detail x isn't feasible.