[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

[Justin Kolb]

It seems that while similar to tuples, fixed sized arrays are definitely not a tuple.

1.) There would be a need for two forms of tuple indexing, most likely leading to confusion and complexity.
2.) When a new user wants a fixed size array they aren’t looking for special casing of a tuple, they are going to look in the arrays documentation and not find what they are looking for.
3.) Tuples are generally compile time checked, arrays are usually not.
4.) The count of a tuple isn’t a very useful operation, but on an array it is essential.
5.) The memory layout of a tuple should prefer to be ambiguous (even if it is essentially the same as a fixed array) while a fixed array has a very specific and relied upon memory layout in order to make it useful in low level scenarios.

While researching this I came across the syntax that Rust uses for its fixed size arrays which in Swift would be:

var a: [Int; n] // Where n is a compile time constant

While this is very similar to the existing array syntax I think it is different and straight forward enough that people expecting a dynamic array would use [Int] and a fixed array to be [Int; n], and would allow them to be discussed with each other in the documentation without having to explain why a fixed array would be so vastly different as it would be in the instance it was considered a special case tuple.

I think we have fallen into a trap where it seems like it would be easy to modify tuples to act liked fixed arrays since they somewhat do already. Applying the principle of least surprise I think this is a mistake, when someone wants an array, they want an array. Despite any extra difficulty (that’s not obviously insurmountable) I think it would be beneficial to keep arrays and tuples separate and distinct from each other.

There is still the potential point of confusion that [Int; n] is a low level construct (most likely not allowing user defined methods) while [Int] is syntax sugar for Array<Int>, but I think overall it is still a better trade off and less surprising. It also seems like grammar problems might be lessened when dealing with [] instead of () which is used in more cases.