I haven’t pushed the rewrite code yet. You’ve probably already seen most of the interesting stuff in ArrayInterface, although not examples of using it. I didn’t want to merge the PR in case I want to change things or think of better representations.
It’d just be another SDTuple, that would default to entirely static 1s for most array types, and entirely dynamic for OffsetArrays. But now it’d have the advantage of supporting hybrids.
But maybe it’d be best to just leave this to wrapper types like OffsetArrays.jl.
A disadvantage of the current SDTuple approach is that it encodes the statically known information as a tuple, e.g. (3,4) rather than a Tuple type, as in Tuple{3,4}.
Tuples are far nicer to work with, and I grew tired of the boiler plate. But Tuple types let you do what StaticArrays does:
const SVector{M,T} = SArray{Tuple{M},T,1,M}
const SMatrix{M,N,T,L} = SArray{Tuple{M,N},T,2,L}
So we’d just have to have a function like StaticArrays.Size that’ll convert the Tuple type to a tuple value.
This adds boiler plate to the library authors/people working on internals, but I guess it’s worth it as I suspect users wouldn’t be happy with having types like MySVector{(4,)} or writing code like:
const MySVector{M,T,L} = MySArray{M,T,1,L}
function foo(x::MySVector{MT}) where {MT}
(M,) = MT
for m in 1:M
....
Hopefully methods like sdsize (static-dynamic hybrid size), sdstride (static-dynamic hybrid strides), and known_length on axes make a good foundation for working with possibly static arrays in a generic manner.
Long load time, lots of invalidations making loading other packages slow, on Julia 1.5:
julia> using StaticArrays
julia> @time using Example
0.656540 seconds (1.33 M allocations: 66.060 MiB, 7.79% gc time)
where Example is a dummy module.
But check out the fruits of Tim Holy’s labor, Julia 1.6:
julia> using StaticArrays
julia> @time using Example
0.002901 seconds (2.90 k allocations: 185.891 KiB)
@time using StaticArrays itself goes from about 0.59 to 0.48 s for me on Julia 1.5 vs a build of Julia 1.6 that only has some of these improvements.
Anyway, I think type piracy is also a great reason for chakravala to be interested in defining his own types. That is, he’s likely to want to define his own methods on these arrays that may conflict with the existing methods. E.g., he may want to define his own A \ b method without pirating.
This is why I think a statically sized array interface will be great to have (and why Zach_Chrisensen and I’ve been working on it): don’t reinvent the wheels you don’t plan on improving or experimenting with, and go through an interface so other unrelated packages can benefit from that static sizing information.
