On Wednesday, 9 October 2013 at 16:34:52 UTC, BLM768 wrote:
On Wednesday, 9 October 2013 at 06:48:31 UTC, monarch_dodra
wrote:
OK, so that's two functions already. What about opCmp? What
about toHash?
Since ordered comparisons make no sense with null values, opCmp
would need to throw an exception when working with null values
anyway. That's exactly what it does right now. I've considered
the other operators, and the same logic seems to apply to them.
As for toHash, that needs to be overloaded whenever opEquals
is. That's true for all types.
What if T is a range? Then "Nullable!T.empty" should return
true if the Nullable is empty. IF we don't, we'll get a crash
in foreach.
It does. Null is not an "empty" range; it's the _absence_ of a
range. They are not the same concept, and a null range _cannot_
be empty because the range does not exist. Therefore, it's a
logic error and should throw an exception.
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.
I draw the line when convenience gets in the way of my
programs not crashing.
Whether you have the "alias this" or not, if you try to get a T
out of a null Nullable!T, your program will throw an exception.
Leaving out the "alias this" would serve only as a reminder to
check for null, not as a solution to logic errors. When dealing
with a Nullable!T, just like when dealing with a nullable
object reference or a nullable pointer, you have to account for
the null state.
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"
