Improvements to std.typecons.Nullable

[Andrei Alexandrescu]

On 10/9/13 10:07 AM, monarch_dodra wrote:
> 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'm confused. I thought Nullable!T == T is well defined to mean "true" 
if a value is present and equal to the right-hand side, or "false" 
otherwise (the absence of a value is a singularity unequal with all 
objects). What's harmful about that?

Andrei