On Mon, Mar 19, 2012 at 01:54:27AM +0100, Brian Palmer wrote: [...] > However, this won't work for comparison operators like < and >, which > all map to opCmp, or for != (since that's rewritten to !(a == b)) > > I guess I have two questions, one, am I going to shoot myself in the > foot by going down this path, because it only happens to work due to > the compiler being too lax? And is there interest in extending D to > allow the rest of the operators to return non-boolean results? I'm > thinking something like falling back to opBinary!("<"), etc, if opCmp > isn't defined for a struct.
IIRC, the reason D chose to go with opCmp and opEquals rather than the C++ route of operator...() for each comparison operator is so that the language can give some guarantees about the consistency of a<b, a<=b, a==b, etc.. In C++, for example, you can define operator<() and operator>() in completely arbitrary ways, which means they can be totally unrelated to each other, and return results that have nothing to do with each other. This causes inconsistency in that a<b does not necessarily imply b>a, and vice versa. Which makes for inconsistent code. By using opCmp in D, such inconsistency is avoided, and the user is spared the tedium of having to define operator<(), operator<=(), operator>(), operator>=(), (and in D, you also have to add !<=, !>=, !<, !>, etc.), ad nauseum; a single operator opCmp() takes care of all these cases. T -- Prosperity breeds contempt, and poverty breeds consent. -- Suck.com