I'd like to suggest changing the isnull::Bool field of Nullable to a hasvalue::Bool field with the opposite meaning. Indeed, all languages and formats I could find use this convention. Following the most common convention is generally a good idea, and it's particularly useful when creating NullableArrays from binary formats like Feather.
Of course, this would be a breaking change, but it would only affect code which does not use the public isnull() method. Since that method is a simple accessor to the eponymous field, there's no reason to access the field directly. Potential breakage would easily be fixed before 0.6 is released by changing x.isnull to isnull(x), which works since Julia 0.4.
Here's a short survey of what other software does in that regard:
Nullable type has an HasValue field.Option type has an isDefined method.Valid field.NULL is marked via serial type 0 (equivalent to false in most languages).0 bit (again equivalent to false in most languages) to denote a null.CC: @johnmyleswhite @quinnj @davidagold
R has is.na(), but I find myself almost exclusively doing !is.na(x)
Note that I'm not talking about changing the isnull() function here, only the underlying implementation.
Oh. Well, maybe changing the function is something to consider as well?
I'm on board with this because I think it will simplify using the internals for fast math: you can treat these as frequency-count weights and do things like x.value * x.hasvalue as long as you guarantee the absence of NaN.
Oh. Well, maybe changing the function is something to consider as well?
I'd rather discuss this somewhere else. If you open an issue, please also make a survey of what other languages do (it seems to me isnull() is the most common pattern).
Most helpful comment
I'm on board with this because I think it will simplify using the internals for fast math: you can treat these as frequency-count weights and do things like
x.value * x.hasvalueas long as you guarantee the absence ofNaN.