I also have landed pretty firmly in the “No need for sugar at the present time” camp.
I agree with this. I would very much expect, for example, a graphics library to define things like this:
struct Vector<let count: Int, Element> { ... }
extension Vector where Element: Numeric { ... }
typealias Vec4<Element> = Vector<4, Element>
The Vector type would wrap an InlineArray property, which only gets declared once so any sugar is irrelevant. Then all usage sites would traffic in, eg. Vec4<Float>.
• • •
One thing that is important to have good sugar for, is initializing a Vec4 from an array literal. Specifically, it should be a compile-time error to provide a literal with the wrong number of elements:
let u: Vec4 = [1, 2, 3] // error: too few elements
let v: Vec4 = [1, 2, 3, 4] // good
let w: Vec4 = [1, 2, 3, 4, 5] // error: too many elements
The original InlineArray proposal SE–453 talks about this in the Future Directions section, and I think we need to have a good solution here before we can consider InlineArray to be “fully baked” and ready for widespread use.
• • •
Once we have that available, so people can make types that are “expressible by fixed-length array literal”, then we will be able to see how programmers actually use InlineArray in practice—which I expect will often involve a thin wrapper type to provide domain-specific functionality such as vector arithmetic.
When that happens, then after some time has passed we can revisit the current proposal in light of the collective knowledge that the Swift community has gained from real-world experience using InlineArray with domain-specific wrapper types.
In summary, I believe that SE–483 should be deferred until a future date, once sufficient time has passed after the introduction of the ability to express custom types by fixed-length array literals.