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


Jonathan M Davis <jmdavisp...@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisp...@gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisp...@gmx.com> 2012-02-03 10:41:55 
PST ---
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: -------

Reply via email to