www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7430] New: opCmp doesn't support unordered value comparison.

reply d-bugmail puremagic.com writes:
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



---
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7430


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7430




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



 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7430




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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7430


dawg dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg dawgfoto.de



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