zeros, rand, randn could infer the length parameter of incompletely parameterized StaticArrays

[mikmoore]

From https://discourse.julialang.org/t/why-does-smatrix-allocate-in-this-case/127808.

julia> zeros(SMatrix{2,2,Float32,4}, 1)
1-element Vector{SMatrix{2, 2, Float32, 4}}:
 [0.0 0.0; 0.0 0.0]

julia> zeros(SMatrix{2,2,Float32}, 1) # container is incompletely typed
1-element Vector{SMatrix{2, 2, Float32}}:
 [0.0 0.0; 0.0 0.0]

The same behavior happens for rand, randn, and probably any others in this family. And also for the MArray type.

It seems that it should be possible for the function to infer a missing length parameter and use it for the container's type.

[thchr]

For zeros (and ones), the reason this happens is that it falls back to a Base implementation of the kind

function $fs(::Type{T}, dims) where T
    A = Array{T}(undef, dims)
    fill!(A, $f(T))
end

where e.g., fs = :zeros and f = :zero. StaticArrays' zero implementation correctly figures out the omitted type parameters in zero, but the pre-allocated array doesn't figure it out. You could argue the implementation should be:

$fs(::Type{T}, dims) where T = fill($f(T), dims)

I don't know why it isn't: but it should probably be a fix in Julia rather than StaticArrays. It's a somewhat analogous thing for randn and randexp, but the methods are inherited from the Random stdlib (and a fill approach wouldn't work).

For rand, the methods are actually defined in StaticArrays - but those methods should probably be removed since they do the same thing as the fallback definition in Random.

[jishnub]

Implementing zeros in terms of fill may not be possible in general, if the zero element isn't of the same type. To be precise, the result may not have the same eltype.

JuliaLang/julia#54767 (comment)

One (hacky) solution might be to dispatch on the zero element as well, which may then be extended elsewhere.