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.
* Making isNull() @property
get() might also make more sense as a property, but not with
its current name; it would be better to make the name a noun
such as "value" rather than a verb. If it were to be changed,
it could be done in a fully backward-compatible way by making
"get" an alias of "value".
These would all be simple changes, so if someone's willing to
guide me through the formalities, I could make this my first
contribution to Phobos.
Or we could just nuke the alias this. A Nullable!T isn't a T.
It's a T handler. "alias this" allows implicit cast, which should
only happen with a "is a" relation. Using it in a different
context (such as nullable) is wrong, and these errors are the
price we are paying for it. It's a bit more verbose, but it would
solve *all* of these ambiguity and unexpected error problems.
I would much rather we push in that direction instead.
This also holds true for RefCounted btw.
That's my take on it.
