copyto! breaking change in v1.5

[goretkin]

using OffsetArrays

oa = fill(1, (3:5, 3:5))
copyto!(Array{Int,2}(undef, size(oa)), oa)

On v1.4:

ERROR: BoundsError: attempt to access 3×3 Array{Int64,2} at index [3:5, 3:5]
Stacktrace:
 [1] throw_boundserror(::Array{Int64,2}, ::Tuple{OffsetArrays.IdOffsetRange{Int64,Base.OneTo{Int64}},OffsetArrays.IdOffsetRange{Int64,Base.OneTo{Int64}}}) at ./abstractarray.jl:537
 [2] checkbounds at ./abstractarray.jl:502 [inlined]
 [3] copyto!(::Array{Int64,2}, ::OffsetArray{Int64,2,Array{Int64,2}}) at ./multidimensional.jl:959
 [4] top-level scope at none:0

via a dispatch to

julia/base/multidimensional.jl

Lines 958 to 965 in 44fa15b

	function copyto!(dest::AbstractArray{T1,N}, src::AbstractArray{T2,N}) where {T1,T2,N}
	checkbounds(dest, axes(src)...)
	src′ = unalias(dest, src)
	for I in eachindex(IndexStyle(src′,dest), src′)
	@inbounds dest[I] = src′[I]
	end
	dest
	end

whereas on v1.5 it does not throw.

f345c5f may be the cause.

[goretkin]

I don't have such a strong opinion that the copyto! behavior be restored. I do think the following is very bad:

julia> VERSION
v"1.5.0-beta1.0"

julia> using OffsetArrays

julia> r = Ref(fill(1, (Base.OneTo(3), Base.OneTo(3))))
Base.RefValue{Array{Int64,2}}([1 1 1; 1 1 1; 1 1 1])

julia> r[] = fill(2, (3:5, 3:5))
3×3 OffsetArray(::Array{Int64,2}, 3:5, 3:5) with eltype Int64 with indices 3:5×3:5:
 2  2  2
 2  2  2
 2  2  2

julia> r[]
3×3 Array{Int64,2}:
 2  2  2
 2  2  2
 2  2  2

[timholy]

The new behavior is correct according to copyto!'s docstring, which is typically the authoritative source. I haven't dug into the other issue, but it indeed looks like a bug.

[JeffBezanson]

From triage: this is ok for copyto!, but not for convert, since an OffsetArray is not == to the same data inside an Array. We need to add a check to convert.

[KristofferC]

Bump, anyone looking at this?

[timholy]

The hard question is whether Array(OA) should throw an error or just convert(Array, OA). I favor throwing an error for both, but it is not obvious.