http://d.puremagic.com/issues/show_bug.cgi?id=10771
--- Comment #3 from [email protected] 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: -------
