Improvements to std.typecons.Nullable

[Paolo Invernizzi]

On Wednesday, 9 October 2013 at 06:48:31 UTC, monarch_dodra wrote:
> On Tuesday, 8 October 2013 at 19:04:33 UTC, BLM768 wrote:
>> I've been working on a project that makes relatively heavy use 
>> of nullable values. I've been using std.typecons.Nullable, and 
>> it mostly works well, but there are some improvements that 
>> could be made to the implementation:
>>
>> * A toString() method (needed to fix bug #10915)
>> * An opEquals for comparisons with the type that the Nullable 
>> wraps
>>  * Currently, comparing a null Nullable!T with a T produces an 
>> error,
>>    but it makes more sense to just return false.
>
> OK, so that's two functions already. What about opCmp? What 
> about toHash?
>
> 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.
>
>> On Tue, 08 Oct 2013 22:55:34 +0200
>> "monarch_dodra" <monarchdodra at gmail.com> wrote:
>> > 
>> > A Nullable!T isn't a T. It's a T handler.
>> 
>> I see that as an (unavoidable) implementation detail.
>
> 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.
>
>> Personally, I find Nullable's "alias this" functionality to be 
>> a
> wonderful convenience. FWIW.
>
> I draw the line when convenience gets in the way of my programs 
> not crashing.

I think that there are some situation where the aliased nullable 
is just very handy, especially when you are adapting previous 
written code, but all that considerations are interesting.

It would be wonderful to have some sort of linked "rationale", 
with pro and versus, with suggested use cases and possible 
pitfall, just in the ddoc section of the module: some sort of 
community-driven wiki page?
--
Paolo Invernizzi