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" <monarchdo...@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.
