Deprecate `@SVector`, `@SMatrix`, and `SA[...]` in favor of `@SArray [...]`?

[hyrodium]

The SA notation was introduced in https://github.com/JuliaArrays/StaticArrays.jl/pull/633, and @SArray macro exists from the beginning. Both features have the same purpose: "Provide simple ways to construct SArray!".

I now think it would be nice to deprecate the methods other than @SArray. Here's why:

Disadvantages with SA[...]

• SA[;;;] is not correct.
  • We can fix this, but we also can deprecate SA and reduce the maintenance cost.
  • @SArray [;;;] works fine. (x-ref: https://github.com/JuliaArrays/StaticArrays.jl/pull/1009)
• SA[1,2,3] is not consistent with Float64[1,2,3] etc.
  • There was a discussion about this before: https://github.com/JuliaArrays/StaticArrays.jl/issues/691#issuecomment-555338011.
  • The abstract type SA seems hacky to me just like Tuple{1,2,3} (https://github.com/JuliaArrays/StaticArrays.jl/issues/807)
  • It does not produce actual problems, but I think it confuses beginners.
• SA[...] creates SArray, but no similar features for MArray.
  • @MArray [1 2;3 4] is shorter than MMatrix(SA[1 2; 3 4]). (https://github.com/JuliaArrays/StaticArrays.jl/issues/691#issuecomment-555338011)
• SA[i for i in 1:3] is not supported.
  • @SVector [i for i in 1:3] works.
• No similar features to @SArray rand(3) etc.

Disadvantages with @SVector and @SMatrix

• @SArray is enough. No additional benefits.

Disadvantages with @SArray

• @SArray [1,2,3] needs more keystrokes than SA[1,2,3]

[mateuszbaran]

I don't really like SA either. I wouldn't make any formal deprecation but I think rewriting README.md to promote @SArray/@MArray as the primary convenient way of making static arrays is a good idea.

@SVector is used in so many packages that JuliaHub gives up shortly after reaching letter "C": https://juliahub.com/ui/Search?q=%40SVector&type=code .

[hyrodium]

Okay, I will open a PR to update the docs not to encourage @SVector, @SMatrix, and SA[...]. :+1: