www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10771] New: std.typecons.Nullable throws an exception on comparision of null values

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10771

           Summary: std.typecons.Nullable throws an exception on
                    comparision of null values
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: qaston gmail.com


--- Comment #0 from QAston <qaston gmail.com> 2013-08-07 10:58:50 PDT ---
The following code should work and assert should pass.
On dmd 2.063.2 assert "Called `get' on null Nullable!Test" occurs instead
---
import std.typecons;
void main()
{
    struct Test{
        int a;
    }
    Nullable!Test a;
    Nullable!Test b;
    assert(a==b);
}
---

So, IMO Nullable!T needs opEquals implemented.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 07 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10771


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra gmail.com


--- Comment #1 from monarchdodra gmail.com 2013-08-08 10:31:03 PDT ---
(In reply to comment #0)
 The following code should work and assert should pass.
 On dmd 2.063.2 assert "Called `get' on null Nullable!Test" occurs instead
 ---
 import std.typecons;
 void main()
 {
     struct Test{
         int a;
     }
     Nullable!Test a;
     Nullable!Test b;
     assert(a==b);
 }
 ---
 
 So, IMO Nullable!T needs opEquals implemented.
I'm not sure it should. It would blend the notion of *what* the comparison compares. For example, in the opposite case: Nullable!Test a; Nullable!Test b = 5; if (a == b) ... //Legal ? Arguably, this is a mistake, as a null was used in a comparison. But it now simply returns false. And I don't think it's OK to assert when *one* of both are null, yet not both, so I'm not entirely sure about the proposed enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10771



--- Comment #2 from QAston <qaston gmail.com> 2013-08-08 11:16:05 PDT ---
(In reply to comment #1)
 I'm not sure it should. It would blend the notion of *what* the comparison
 compares. For example, in the opposite case:
 
     Nullable!Test a;
     Nullable!Test b = 5;
 
     if (a == b) ... //Legal ?
 
 Arguably, this is a mistake, as a null was used in a comparison. But it now
 simply returns false.
 
 And I don't think it's OK to assert when *one* of both are null, yet not both,
 so I'm not entirely sure about the proposed enhancement.
I forgot to say that I'd expect the case you posted as legal as well. I thought that this was a simple analogy to how null works in the language, but apparently at the time of posting I forgot that null is never compared with opEquals, it uses [is] operator instead. Phobos doc state that Nullable: "Defines a value paired with a distinctive "null" state that denotes the absence of a value." I was paying more attention to the "distinctive state" than to the "absence of a value". Now I see that it makes no sense to compare absences. In my case it was useful however, so maybe this may be a candidate for a separate type or template flag. Anyways comparision semantics should be mentioned in the doc imo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 08 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10771



--- Comment #3 from monarchdodra gmail.com 2013-08-09 05:38:51 PDT ---
(In reply to comment #2)
 (In reply to comment #1)
 I'm not sure it should. It would blend the notion of *what* the comparison
 compares. For example, in the opposite case:
 
     Nullable!Test a;
     Nullable!Test b = 5;
 
     if (a == b) ... //Legal ?
 
 Arguably, this is a mistake, as a null was used in a comparison. But it now
 simply returns false.
 
 And I don't think it's OK to assert when *one* of both are null, yet not both,
 so I'm not entirely sure about the proposed enhancement.
I forgot to say that I'd expect the case you posted as legal as well. I thought that this was a simple analogy to how null works in the language, but apparently at the time of posting I forgot that null is never compared with opEquals, it uses [is] operator instead. Phobos doc state that Nullable: "Defines a value paired with a distinctive "null" state that denotes the absence of a value." I was paying more attention to the "distinctive state" than to the "absence of a value". Now I see that it makes no sense to compare absences.
Well, this is up to debate of course. I'd agree with you if Nullable was a reference type, in which case, "==" would compare the references, and "a.get == b.get" or "a == 5" would be actual value comparisons. Unfortunatly, Nullable is a value type, so I think it is safer to consider a "null Nullable" as simply something you can't use or even compare to anything. That's what I think anyways.
 In my case it was useful however, so maybe this may be a candidate for a
 separate type or template flag. Anyways comparision semantics should be
 mentioned in the doc imo.
RefCounted, (which uses reference semantics) may do what you need? If you don't care for reference counting, then... raw pointers? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 09 2013