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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------