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" <[email protected]> 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
