As usual such change turns out to break DataFrames.jl tests which assumed this method is not defined 😄. I will fix it in the package.

For a reference - we defined in using haskey. Not sure if such things also happen in other packages.

Also is this intended:

julia> haskey((1,2,3), 1)
true

julia> haskey((1,2,3), 1.0)
true

julia> haskey((a=1,b=2,c=3), 1)
true

julia> haskey((a=1,b=2,c=3), 1.0)
false

?

and:

julia> haskey([1,2,3], 1.0)
true

julia> [1,2,3][1.0]
ERROR: ArgumentError: invalid index: 1.0 of type Float64

Is this change really a good idea? What's the rationale? I'm afraid it's going to create some confusion as @bkamins shows.

That is a bit of a tricky case, when some types (e.g. arrays) define a different value-equivalence class than the usual convert definitions

when some types

I agree, however, my concern was that these "some types" are fundamental types that are most commonly used in practice.

The alternative would be to make sure that we define proper haskey methods for all types defined in Julia Base and make sure they work consistently.

In addition to @bkamins examples, is this also expected?

julia> haskey([1, 2, 3], CartesianIndex(2))
false

julia> [1, 2, 3][CartesianIndex(2)]
2