Restrict vector indexing of views to 1-based ranges#53249
Conversation
|
Is the real root problem in broadcast? To be concrete, indexing a julia> v = [1:5;];
julia> v[Base.IdentityUnitRange(2:3)]
ERROR: MethodError: no method matching similar(::Vector{Int64}, ::Type{Int64}, ::Tuple{Base.IdentityUnitRange{UnitRange{Int64}}})This SubArray method is forwarding a (potentially offset) index to a parent, which should end up in that same situation. But it's the broadcasted addition with the SubArray's offset that's causing the trouble: julia> 0 .+ Base.IdentityUnitRange(2:3)
2:3
julia> axes(ans)
(Base.OneTo(2),)Surely those axes should similarly be offset, yeah? In fact, I think this is an overzealous julia> Ref(0) .+ Base.IdentityUnitRange(2:3)
ERROR: MethodError: no method matching similar(::Type{Array{Int64}}, ::Tuple{Base.IdentityUnitRange{UnitRange{Int64}}}) |
|
Yeah, the real bug is that all these methods assume 1-based axes: Lines 1100 to 1168 in a0989f4 |
|
But that's a much bigger issue (see #30950 😳) — and the restriction on this particular optimization seems like a good solution for the immediate problem. This just needs tests here — would be good to have two sets; one in test/offsetarray and one without them. |
|
I had actually added tests without offset arrays that I subsequently removed in 188c7fc. I fear that if the Adding a test to check that an offset array is returned when |
|
Should this be merged? |
This will be an offset array in general, so we need to restrict the method to 1-based ranges. This restores the behavior on
v"1.10".The method was added in #45371