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



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





 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






 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








 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