Add DenseArray <: AbstractStrided <: AbstractArray #50275
Description
The intent being "if you implement strides, then you should <: AbstractStrided instead of AbstractArray.
#2345 is 10 years old now. There still isn't a way to say "I have this function that requires that the array implements the strides method, even if it isn't Array or SubArray. There's still need for this.
It seems to me the problem with #2345 is that it started with a very concrete small change, and devolved into a discussion of how to fix typing of arrays in Julia in general, which was not resolved.
I'm proposing we do not address this larger issue here. Just add a new DenseArray <: AbstractStrided <: AbstractArray, and make SubArray <: AbstractStrided.
I'm not proposing deleting the current StridedArray union, as this will break code. In contrast, this proposal doesn't break any existing code.
It seems like a tiny change:
- Add
abstract type AbstractStrided{T,N} <: AbstractArray{T,N} end. - Change
abstract type DenseArray{T,N} <: AbstractArray{T,N} endtoabstract type DenseArray{T,N} <: AbstractStridedT,N} end. - Change
struct SubArray{T,N,P,I,L} <: AbstractArray{T,N}tostruct SubArray{T,N,P,I,L} <: AbstractStrided{T,N}.
That's it.
It would have been nice if this was done instead of creating the original StridedArray union, but that's in the past. So StridedArray union becomes "the strided version of [Sub]Array. There's value in that.
Just adding this will not magically update existing packages that today either require DenseArray which is an overkill (like Strided.jl), or just give up and use AbstractArray (like PythonCall.jl). But once this is in the standard library, such packages will eventually start using it.
Is there any downside? Why not "just do it"?