Array constructors using `StaticInt` as dimensions

[chriselrod]

julia> zeros(static(4))
ERROR: MethodError: no method matching zeros(::StaticInt{4})
Closest candidates are:
  zeros(::Tuple{Vararg{Union{Integer, AbstractUnitRange}}}) at array.jl:582
  zeros(::Type{StaticArrays.MVector{N}}) where N at ~/.julia/packages/StaticArrays/0T5rI/src/MVector.jl:20
  zeros(::Type{StaticArrays.SVector{N}}) where N at ~/.julia/packages/StaticArrays/0T5rI/src/SVector.jl:19
  ...
Stacktrace:
 [1] top-level scope
   @ REPL[13]:1

julia> Array{Int}(undef, static(4))
ERROR: MethodError: no method matching (Array{Int64})(::UndefInitializer, ::StaticInt{4})
Closest candidates are:
  (Array{T})(::Nothing, ::Any...) where T at baseext.jl:45
  (Array{T})(::UndefInitializer, ::Tuple{Vararg{Int64, N}}) where {T, N} at boot.jl:478
  (Array{T})(::UndefInitializer, ::Tuple{Vararg{Integer, N}}) where {T, N} at baseext.jl:35
  ...
Stacktrace:
 [1] top-level scope
   @ REPL[14]:1

But it may be nice to pick a blessed package like StrideArraysCore for some of these (e.g. zeros, ones) to construct arrays with statically sized dimensions.

[Tokazama]

But it may be nice to pick a blessed package like StrideArraysCore for some of these (e.g. zeros, ones) to construct arrays with statically sized dimensions.

I think this eventually should happen but I'm nervous to make a decision. It seems like one of those things that will upset people no matter what package we choose.

[chriselrod]

I have some changes planned for StrideArraysCore when I get the time (mostly, don't store explicit strides whenever they can be calculated from size), at which point I think it'd make sense to use them as a blessed "ArrayInterface" and nesting/wrapper-free package. Or develop a new ArrayInterfaceArrays.jl for that purpose, in which case JuliaSIMD would switch to using that array.

[chriselrod]

I got Polyester.jl's tests passing locally, but the testsuite creates a lot of arrays using CPUSummary.numthreads() which returns StaticInt, but zeros(numthreads()) now errors, so those calls largely had to be replaced with Int(numthreads()).

[Tokazama]

I see, so this is actually causing downstream test failures. In an ideal world we could just put a linear buffer inside ReshapedArray that can store StaticInt. But the powers that be haven't deemed StaticInt appropriate for base, so it would be nice if we could have a relatively light weight package that facilitates this.

[chriselrod]

I see, so this is actually causing downstream test failures. In an ideal world we could just put a linear buffer inside ReshapedArray that can store StaticInt. But the powers that be haven't deemed StaticInt appropriate for base, so it would be nice if we could have a relatively light weight package that facilitates this.

Another example of resulting test failures, but here from within a package rather than within the test suite: https://github.com/PumasAI/SimpleChains.jl/runs/7045158658?check_suite_focus=true

[Tokazama]

Previously related functions were just converting to Int and constructing an Array, right? Should we see if we can just replicate the previous behavior so things work until we have a full solution prepared for a statically sized array?