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

[hyrodium]

The SA notation was introduced in #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: Extend @SArray (nested cat, 1.7 syntax) #1009)
• SA[1,2,3] is not consistent with Float64[1,2,3] etc.
  • There was a discussion about this before: @SArray namespace hygiene #691 (comment).
  • The abstract type SA seems hacky to me just like Tuple{1,2,3} (Use StaticIntegers instead of Tuple{1,2,3} in StaticArray type parameter? #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]). (@SArray namespace hygiene #691 (comment))
• 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[...]. 👍