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