Would be useful for many packages, JuliennedArrays, LightQuery, SplitApplyCombine, MappedArrays, Query, etc. Base already has an AbstractEltypelessArray: the lazy broadcast machinery, it would just be a matter of formalizing the interface. Given that traits aren't coming any time soon, it couldn't be <: AbstractArray
, so we would have to duplicate all of the machinery for AbstactArrays
. I could try to build a prototype if people are interested?
I think it would be more realistic to use eltype Any
, and try to get things working as well as possible with such arrays.
Oh, ok, if that would be easier.
Ok, while I'm at it, it would be nice to have abstractarray machinery for all sorts of things, zips of arrays, generators of arrays
Actually, we could just change most AbstractArray functions to be Union{AbstractArray, AbstractEltypelessArray} and nip the problem in the bud, I think.
Took a shower, came back, and realized that because this is a meaningful subtype relationship, we don't need traits or Unions. PR coming.
"""
abstract type Arraylike{Dimensions} end
Things that have a shape, but not a compile-time [`eltype`](@ref). Use
[`AbstractArray`] if you know the eltype at compile-time.
"""
abstract type Arraylike{Dimensions} end
abstract type AbstractArray{Item, Dimensions} <: Arraylike{Dimensions} end
TADA problem solved
Welp, its not that easy because AbstractArray is implemented in C according to boot.jl. I'll punt on making a PR.
The type is not compile time.
:+1: for this direction. I needed to emulate Arraylike
using Union
when implementing mapreduce for Broadcasted #31020. There was a small discussion in https://github.com/JuliaLang/julia/pull/31020#discussion_r255292414
@JeffBezanson this is the stickingpoint for adding JuliennedArrays functionality to base. I was looking through src to see how hard it would be to add Arraylike to base. I see that Signed is added in base/boot.jl, and Int64 is added in src/builtins.c, but where is the code that says Int64 <: Signed?
See discussion in #34196
Most helpful comment
I think it would be more realistic to use eltype
Any
, and try to get things working as well as possible with such arrays.