digitalmars.D.bugs - [Issue 7430] New: opCmp doesn't support unordered value comparison.
- d-bugmail puremagic.com (25/25) Feb 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7430
- d-bugmail puremagic.com (9/9) Feb 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7430
- d-bugmail puremagic.com (27/27) Feb 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7430
- d-bugmail puremagic.com (9/31) Feb 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7430
- d-bugmail puremagic.com (24/24) Feb 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7430
- d-bugmail puremagic.com (7/7) Feb 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7430
- d-bugmail puremagic.com (12/12) Feb 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7430
http://d.puremagic.com/issues/show_bug.cgi?id=7430 Summary: opCmp doesn't support unordered value comparison. Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: gor boloneum.com --- Comment #0 from Gor Gyolchanyan <gor boloneum.com> 2012-02-03 08:55:39 PST --- I have a structure, that represents an element of a range. Let's say a character. That character can be invalid. I need all comparison operators to return false of at least one of the operands is invalid. with opCmp, the expression a b is rewritten as a.opCmp(B) 0, which doesn't allow me to define such a logic. A rewrite of opCmp to test for exact values -1, 0 and 1 would solve the problem, because any value beyond the expected three would cause all comparisons to fail. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7430 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yebblies gmail.com Severity|blocker |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7430 Jonathan M Davis <jmdavisProg gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmdavisProg gmx.com --- Comment #1 from Jonathan M Davis <jmdavisProg 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: -------
Feb 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7430 --- Comment #2 from Gor Gyolchanyan <gor 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: -------
Feb 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7430 Simen Kjaeraas <simen.kjaras gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simen.kjaras gmail.com --- Comment #3 from Simen Kjaeraas <simen.kjaras gmail.com> 2012-02-03 12:55:20 PST --- "a b is rewritten as a.opCmp(B) 0" And there you have it. What return type and value for opCmp fulfills this requirement? I'll tell you: float and nan. Example: struct Foo { float opCmp(Foo other) { return float.nan; } } unittest { assert( !(Foo() < Foo() )); assert( !(Foo() <= Foo()) ); assert( !(Foo() > Foo() )); assert( !(Foo() >= Foo() )); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7430 --- Comment #4 from Simen Kjaeraas <simen.kjaras gmail.com> 2012-02-03 12:57:09 PST --- Oh, there is one problem - opEquals. If it returns true for ==, it returns false for !=. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 03 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7430 dawg dawgfoto.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dawg dawgfoto.de --- Comment #5 from dawg dawgfoto.de 2012-02-03 13:56:07 PST --- Probably making opCmp templated would make sense, wouldn't work for classes though. Adding more return values is a bad idea. It is already difficult enough to write an efficient opCmp with three cases. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 03 2012