http://d.puremagic.com/issues/show_bug.cgi?id=7430
--- Comment #2 from Gor Gyolchanyan <g...@boloneum.com> 2012-02-03 11:52:59 PST --- What i want is a floating-point style comparisons, where there's a NaN, which fits perfectly in the comparison operators and really does return false in all cases. (In reply to comment #1) > So, what are you really asking here? That opCmp in general require that the > result be -1, 0, or 1 or it will return false? That's not going to work. Too > much code relies on the current semantics of opCmp, and it's often _desirable_ > that it not matter whether the values are exactly -1 or 1 but rather just > require that they be less than or greater than 0 as they are now. > > Also, making it so that both <, <=, >=, and > were all false (or all true) > would thoroughly break boolean logic and could have all kinds of nasty > consequences - especially in generic code. One of the major reasons of > creating > opCmp instead of having operator<, operator<=, etc. is so that those > operations > be consistent, which your suggestion violates completely. > > Why can't you just use a custom comparison function for whatever comparisons > you're trying to do? > > Not to mention, I believe that the common way to handle the use case of an > invalid element is to throw. That's what Phobos' UTF stuff does. > > What are you really asking here? That opCmp always test that its return value > is -1, 0, or 1? Because if that's what you're really asking here, then that's > not going to happen. It would break a lot of existing opCmp functions and > quite > purposely is not how opCmp works. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------