Since the original fixed-size array thread is somewhat stalling, I forked off the subscript part into this: Treat uniform tuples as collections <https://github.com/zneak/swift-evolution/blob/uniform-tuples/proposals/00nn-collectiontype-for-tuples.md>
Treat uniform tuples as collections
Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author(s): Swift Developer <https://github.com/swiftdev>
Status: Awaiting review
Review manager: TBD
This proposal aims at adding collection operations to uniform tuples: tuples in which every element has the same type, and no element has a label.
Swift-evolution thread: Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type) <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009520.html>
Fixed-size arrays in C structures are imported as tuples. This means that on the Swift side, developers therefore lose the ability to use even the most basic collection type operations on them, like subscripts. When collection operations are needed, it is usually necessary to transform the tuple into a full-fledged Swift Array using unsafe pointers.
This proposal suggests adding CollectionType conformance to uniform tuples.
Any tuple of more than one element, in which every element has the same type, is eligible for CollectionType conformance. CollectionType elements are generated as such:
Generator: opaque. Possibly based off UnsafeBufferPointers, possibly the same for all uniform tuples (to a generic parameter).
SubSequence: Array, since tuples are value types and cannot be shared without being copied wholesale anyway, and the dynamic nature of SubSequence means that it usually is impossible to simply return a smaller tuple (whose size has to be known at compile-time).
count: the number of elements in the tuple.
subscript(_: Self.Index): single element at given index. Bounds-checked.
subscript(_: Range<Self.Index>): sub-sequence Array. Bounds-checked.
It is worth noting that uniform tuples do not lose static field access. This avoids needlessly breaking existing code and allows developers to bypass bounds-checking for indices known to be safe.
Impact on existing code
No impact on existing code; the feature is purely additive.
A simpler syntax to declare uniform tuples from Swift, like (Int x 4), was found to be contentious. This proposal forks off the original for incremental implementation of the feature.
The original proposal only called for a subscript on uniform tuples. Adding full CollectionType support seemed simple enough and useful enough to suggest it.
It was suggested that uniform tuples should lose their static field access syntax to ensure that there is Just One Way to access tuple elements. However, this could have surprising side effects on existing code and wouldn't be possible with generic code.