[Issue 10771] std.typecons.Nullable throws an exception on comparision of null values

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=10771



--- Comment #4 from QAston <qaston at gmail.com> 2014-01-19 05:29:32 PST ---
(In reply to comment #3)
> (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?

I want something like Optional(T), which compares null and non-null uniformly
instead of having a distinction like it is now for classes with is and
opEquals. Nullable is intended to emulate behavior of null for classes so
current implementation is ok and this bug can be closed.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------