On Wednesday, 9 October 2013 at 17:07:18 UTC, monarch_dodra wrote:
That was my point. Writting "Nullable!T == T" is the exact same
thing: Comparison of a value with the absence of a value. It's
neither equal nor different, it's an error.
Equality comparison is a bit different from properties such as
emptiness. Virtually every language allows comparisons between
null and non-null objects. In D and Java, this is the behavior
for object references; in Ruby and Lua, this is the behavior for
all values. Nullable!T was seemingly designed to emulate that
sort of behavior, and overloading opEquals() would provide
semantically correct behavior without any exceptions ever being
thrown.
My point though is that it's implicit nature makes it so that
you forget about said state.
Adding a simple ".get()" is not that much verbose, and sticks
out that you are calling something that can be an error. You
should either be operating the handler (Nullable), or the Value
itself. Not a bit of "maybe the nullable, maybe the value"
Ultimately, it seems to boil down to a personal preference:
should Nullable!T emulate the behavior of D's existing nullable
types, or should it use a more explicit syntax? I personally lean
toward consistency, in part because doing otherwise would be a
breaking change that doesn't really seem justified unless we can
solve the issue with _all_ nullable references. I do see the
merits of your proposal, though.
