-
Notifications
You must be signed in to change notification settings - Fork 152
Open
Description
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
SAand reduce the maintenance cost. @SArray [;;;]works fine. (x-ref: Extend@SArray(nested cat, 1.7 syntax) #1009)
- We can fix this, but we also can deprecate
SA[1,2,3]is not consistent withFloat64[1,2,3]etc.- There was a discussion about this before: @SArray namespace hygiene #691 (comment).
- The abstract type
SAseems hacky to me just likeTuple{1,2,3}(UseStaticIntegers instead ofTuple{1,2,3}inStaticArraytype parameter? #807) - It does not produce actual problems, but I think it confuses beginners.
SA[...]createsSArray, but no similar features forMArray.@MArray [1 2;3 4]is shorter thanMMatrix(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
@SArrayis enough. No additional benefits.
Disadvantages with @SArray
@SArray [1,2,3]needs more keystrokes thanSA[1,2,3]
Metadata
Metadata
Assignees
Labels
No labels