Why does Base define:
==(x::Nullable, y::Nullable) = throw(NullException())
It means even something as simple as :
Nullable(0.39) in [Nullable(0.39)]
returns a NullException(). It somewhat limits the utility of the Iterable Collections abstractions when using Nullables.
That’s because == falls back to === by default, so Nullable("a") == Nullable("a") would return false. The choice to return an error was made because we couldn’t decide whether == applied to Nullable should return a Bool or a Nullable{Bool} (to follow three-valued logic).
Maybe we should revisit this. For now, you can use isequal instead (of course that doesn’t work for in).
Another option might be to use DataValue from the DataValues.jl package instead of Nullable. It has a == method that does what you want.
I initially created the package to get around exactly these kinds of problems with Nullable in Query.jl.
Gentlemen,
thank you for your responses. I will have a look at Datavalues.jl.
As I understand it Julia(0.6 RC3) treats a Null as greater than any value, while two Nulls are treated as equal.
But why not set == to to isequal? At least then Collections abstractions would work with the defined logic
NullableArrays defines ==, although it’s essentially type-piracy…
julia> using NullableArrays
WARNING: Method definition ==(Base.Nullable{S}, Base.Nullable{T}) in module Base at nullable.jl:238 overwritten in module NullableArrays at /Users/cedric/.julia/v0.6/NullableArrays/src/operators.jl:128.
julia> Nullable(1) == Nullable(30)
Nullable{Bool}(false)
Thank you for the pointer cstjean . You have now explained why I saw a sudden change in behaviour with comparisons a few days ago. I was using NullableArrays, but decided to change to Nullable for other reasons.