Override ==, any() and all() for AbstractArray{:>Null}

[nalimilan]

This is needed to return null when needed instead of throwing an error.
The methods will (and have to) also apply to Array{Any}, but "a little bit
type piracy is not the end of the world", at least temporarily.

[ararslan]

but "a little bit of type piracy is not the end of the world", at least temporarily.

grumble grumble

[cjprybol]

I wouldn't have thought to use === for checking booleans before seeing this, but it's noticably faster

julia> @benchmark false === false
BenchmarkTools.Trial:
  memory estimate:  0 bytes
  allocs estimate:  0
  --------------
  minimum time:     0.038 ns (0.00% GC)
  median time:      0.048 ns (0.00% GC)
  mean time:        0.052 ns (0.00% GC)
  maximum time:     14.335 ns (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     1000

julia> @benchmark false == false
BenchmarkTools.Trial:
  memory estimate:  0 bytes
  allocs estimate:  0
  --------------
  minimum time:     2.353 ns (0.00% GC)
  median time:      2.958 ns (0.00% GC)
  mean time:        3.835 ns (0.00% GC)
  maximum time:     4.157 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     1000

is there any reason to not always use === rather than == for boolean comparison?

[ararslan]

is there any reason to not always use === rather than == for boolean comparison?

In general, boolean comparisons aren't that common, especially in control flow, since it's typically easier to just say if eq or if !eq. In this case === is needed to ensure that null doesn't propagate in the comparison.

[nalimilan]

I wouldn't trust benchmarks on elementary operations like this. Wrapping these in a function gives exactly the same native code.

I could also have used isequal(eq, true), but using === we ensure no other type can override isequal, as "truthiness" isn't considered as a good idea in general in Base Julia.