-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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