Improvements to std.typecons.Nullable
monarch_dodra
monarchdodra at gmail.com
Tue Oct 8 13:55:34 PDT 2013
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.
More information about the Digitalmars-d
mailing list