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

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

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

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