`indexin` should accept Tuples as second argument?

Internals & Design Internals
1

As a side note from this thread, I noticed that the implementation of indexin, which is:

function indexin(a, b::AbstractArray)
    inds = keys(b)
    bdict = Dict{eltype(b),eltype(inds)}()
    for (val, ind) in zip(b, inds)
        get!(bdict, val, ind)
    end
    return Union{eltype(inds), Nothing}[
        get(bdict, i, nothing) for i in a
    ]
end

can be adapted to accept Tuples as the second argument simply by removing the type annotation. I mean, this works:

julia> x = rand(1:10,10); y = ntuple(i->rand(1:10),20);

julia> indexin(x,y)
ERROR: MethodError: no method matching indexin(::Array{Int64,1}, ::NTuple{20,Int64})
Closest candidates are:
  indexin(::Any, ::AbstractArray) at array.jl:2333
Stacktrace:
 [1] top-level scope at REPL[81]:1

# removing the requirement of `b` being an AbstractArray
julia> indexin_new(x,y) 
10-element Array{Union{Nothing, Int64},1}:
  3
 17
  1
  1
 15
  3
   nothing
  8
  2
 17

It seems to work well and perform ok.

Is there any other reason for not accepting Tuples there, or that constraint could be alleviated?

2

Tangentially, I noticed this:

julia> keys([1,2,3])
3-element LinearIndices{1, Tuple{Base.OneTo{Int64}}}:
 1
 2
 3

julia> keys((1,2,3))
Base.OneTo(3)

Since keys of multidimensional array would return CartesianIndices, I wonder what’s the purpose of wrapping OneTo with LinearIndices for vector