Improvements to std.typecons.Nullable

[BLM768]

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.

If your range were class-based, you'd have exactly the same 
issue, except that instead of getting an exception, you'd get a 
segfault.

>> On Tue, 08 Oct 2013 22:55:34 +0200
>> "monarch_dodra" <monarchdodra at gmail.com> wrote:
> Is it though? C++ has done without it, and is still doing 
> without it. It has "implicit build from" which every one says 
> is mostly an abomination. Then here we are, bashing on their 
> implicit constructors, yet using "implicit cast to" O_o.

A major part of the problem in C++ stems from the existence of 
two different forms of implicit conversion: the overloaded cast 
operator and copy-constructors. D does not allow implicit 
conversions with the latter, and it only allows implicit 
conversion to one type with the former, which is considered 
acceptable according to every C++ book I've read.

> 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.