Nullable and ==

question

#1

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.


#2

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).


#3

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.


#4

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


#6

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)

#7

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.