Indices of indices aren't checked in vector `setindex!` with offset arrays

[jishnub]

MWE

julia> a = [1:7;];

julia> a[Base.IdentityUnitRange(3:4)] = 2:3
2:3

julia> a[Base.IdentityUnitRange(3:4)] .= 2:3
ERROR: DimensionMismatch: array could not be broadcast to match destination
Stacktrace:
 [1] check_broadcast_shape
   @ ./broadcast.jl:540 [inlined]
 [2] check_broadcast_axes
   @ ./broadcast.jl:543 [inlined]
 [3] instantiate
   @ ./broadcast.jl:284 [inlined]
 [4] materialize!
   @ ./broadcast.jl:871 [inlined]
 [5] materialize!(dest::SubArray{Int64, 1, Vector{Int64}, Tuple{Base.IdentityUnitRange{UnitRange{Int64}}}, true}, bc::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{1}, Nothing, typeof(identity), Tuple{UnitRange{Int64}}})
   @ Base.Broadcast ./broadcast.jl:868
 [6] top-level scope
   @ REPL[82]:1

Ideally, these two should be equivalent, and the setindex! should really only work if the RHS has the same indices.

[adienes]

wait, I'm getting confused exactly what the ask is. note

The syntax A[inds...] = X is equivalent to (setindex!(A, X, inds...); X).

so isn't

julia> a[Base.IdentityUnitRange(3:4)] = 2:3
2:3

already correct?

[jishnub]

The issue isn't that the result is incorrect, but whether we expect setindex! and a broadcast assignment to behave similarly when the indices have offset axes. In other words, do we iterate over the indices and the value or loop over their indices? Perhaps the answer is that these are just different operations and may not behave identically, in which case the issue may be closed.

[mbauman]

I think the status quo here is exactly what we want... or at least makes some sense and is defensible.

Nonscalar setindex! and broadcasted assignment are different in somewhat complicated ways. If you think of their behaviors in a Venn diagram sort of way, they do have overlapping behaviors:

• (only setindex!) supports linear-indexing-compatible reshapes (and more undocumented shape shenanigans)
• (both) work if axes are an exact match
• (only broadcast) can broadcast the non-matching singleton axes

It's not like one is a "superset" of the behaviors of the other, even ignoring the potential offset-ness. So it's definitely ok for their requirements to be different. I don't think it's necessary (or helpful) to try to project one's behaviors to the other.

So then the question becomes: does (or should) the meaning of setindex! demand that the indices of the RHS and LHS match? I think that the support of reshapes pushes us towards viewing the operation as a "sequential" sort of thing. It does complicate the wording of the behaviors, but I think we'd be in good stead with the proposed wordings in #59025.