[Issue 7430] opCmp doesn't support unordered value comparison.

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Feb 3 11:53:01 PST 2012


http://d.puremagic.com/issues/show_bug.cgi?id=7430



--- Comment #2 from Gor Gyolchanyan <gor at 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: -------


More information about the Digitalmars-d-bugs mailing list