checkbounds should error for floating point indices

[songjhaha]

we could creat a SubArray with a float index like：

julia> A = rand(2,3);
julia> B = @views A[[1.0,2.0]];
julia> typeof(B)
SubArray{Float64, 1, Vector{Float64}, Tuple{Vector{Float64}}, false}

but it's unusable when index a Subarray above:

julia> B[1]
ERROR: ArgumentError: invalid index: 1.0 of type Float64
Stacktrace:
 [1] to_index(i::Float64)
   @ Base .\indices.jl:300
 [2] to_index(A::Vector{Float64}, i::Float64)
   @ Base .\indices.jl:277
 [3] _to_indices1(A::Vector{Float64}, inds::Tuple{Base.OneTo{Int64}}, I1::Float64)
   @ Base .\indices.jl:359
 [4] to_indices
   @ .\indices.jl:354 [inlined]
 [5] to_indices
   @ .\indices.jl:345 [inlined]
 [6] getindex
   @ .\abstractarray.jl:1290 [inlined]
 [7] getindex(V::SubArray{Float64, 1, Vector{Float64}, Tuple{Vector{Float64}}, false}, I::Int64)
   @ Base .\subarray.jl:290
 [8] top-level scope
   @ REPL[11]:1

version and platform:

julia> versioninfo()
Julia Version 1.10.10
Commit 95f30e51f4 (2025-06-27 09:51 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 12 × 11th Gen Intel(R) Core(TM) i5-11500H @ 2.90GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, tigerlake)
Threads: 1 default, 0 interactive, 1 GC (on 12 virtual cores)

[sgaure]

That's an unfortunate behaviour. But how can it be solved? It's possible to create arrays which can be indexed by floats, or bit patterns or something else. And it's quite inefficient to check that every one of the indices can actually be used when creating a view. E.g.

julia> B = @views A[Real[1, 2.0]];

julia> B[1]
0.40751510786433687

julia> B[2]
ERROR: ArgumentError: invalid index: 2.0 of type Float64

I think maybe we have to live with this unfortunate behaviour.
Btw, is there a trait for arrays like IndexType or similar? (not IndexStyle).

[nsajko]

is there a trait for arrays like IndexType or similar?

Something like eltype ∘ keys or eltype ∘ eachindex perhaps:

julia> for v ∈ ([10, 20], BigInt(3):BigInt(7))
           for f ∈ (keys, eachindex)
               trait = eltype ∘ f
               @show trait(v)
           end
       end
trait(v) = Int64
trait(v) = Int64
trait(v) = Int64
trait(v) = BigInt

[mbauman]

Sure, but that's just the "canonical" key. There could be — and are! — many, even for Array.

julia> A = rand(10);

julia> view(A, [0x1,0x2])
2-element view(::Vector{Float64}, UInt8[0x01, 0x02]) with eltype Float64:
 0.6306433236773901
 0.24733675072883643

julia> view(A, Any[0x1,0x2])
2-element view(::Vector{Float64}, Any[0x01, 0x02]) with eltype Float64:
 0.6306433236773901
 0.24733675072883643

Those UInt8s get converted to_indices on the fly. That's quite hard to detect in general: it's a combination of a (possibly non-trivial) to_indices operation and a corresponding getindex method. And the supported indices may even vary by axis. We definitely don't want to eagerly convert the arrays, but we do eagerly check all bounds. So some index arrays are immediately invalid:

julia> view(A, Any[1,'c'])
ERROR: ArgumentError: unable to check bounds for indices of type Char
Stacktrace:
 [1] checkindex(::Type{Bool}, inds::Base.OneTo{Int64}, i::Char)
   @ Base ./abstractarray.jl:751
 [2] checkindex
   @ ./abstractarray.jl:767 [inlined]
 [3] checkbounds
   @ ./abstractarray.jl:689 [inlined]

I think the core issue here is that we have some vestigial checkindex methods for ::Real:

julia/base/abstractarray.jl

Lines 751 to 752 in 1a1270d

	checkindex(::Type{Bool}, inds::AbstractUnitRange, i::Real) = (first(inds) <= i) & (i <= last(inds))
	checkindex(::Type{Bool}, inds::IdentityUnitRange, i::Real) = checkindex(Bool, inds.indices, i)

It'd be great if we could deprecate/remove those in favor of a tighter ::Integer (minus Bool).

[songjhaha]

I expected the indices could be normalized to valid indices or be checked before create subarray. Now errors occur in wrong place which is quite confused.

[sgaure]

Technically, the indices could be normalized when creating a view, but one feature of views is that they should be lightweight to create. Also, it's possible to have a view with out of bounds indices. So, also the bounds check is a convenience, not a foolproof check:

julia> a = [1, 2]
2-element Vector{Int64}:
 1
 2

julia> idx = [2]
1-element Vector{Int64}:
 2

julia> b = view(a, idx)
1-element view(::Vector{Int64}, [2]) with eltype Int64:
 2

julia> idx[1] = 4
4

julia> b
1-element view(::Vector{Int64}, [4]) with eltype Int64:
 135737466509554