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

David Sweeris davesweeris at mac.com
Wed Feb 3 01:57:20 CST 2016

Why does n have to be a compile-time constant? Seems like any integer value >= 0 would be ok.

- Dave Sweeris

Sent from my iPhone
> On Feb 2, 2016, at 20:10, Justin Kolb via swift-evolution <swift-evolution at swift.org> wrote:
> 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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list