[swift-evolution] CollectionType on uniform tuples [forked off Contiguous Variables]

[Thorsten Seitz]

Looks good to me! 

I’m all for keeping the static field access, too, because dropping it would mean having two very different kinds of tuples.

If Swift should ever get union types this proposal can seamlessly be extended to heterogenous tuples which would then conform to CollectionType like proposed but just with an Element type equal to the union of all types present in the tuple.

-Thorsten


> Am 11.02.2016 um 18:12 schrieb Félix Cloutier via swift-evolution <swift-evolution at swift.org>:
> 
> Hi all,
> 
> 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>
> 
> Félix
> 
> 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
> 
> Introduction
> 
> 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>
> Motivation
> 
> 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.
> 
> 
> Proposed solution
> 
> This proposal suggests adding CollectionType conformance to uniform tuples.
> 
> 
> Detailed design
> 
> 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).
> Index: Int.
> 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.
> first: tuple.0
> isEmpty: false
> subscript(_: Self.Index): single element at given index. Bounds-checked.
> subscript(_: Range<Self.Index>): sub-sequence Array. Bounds-checked.
> startIndex: 0.
> endIndex: count.
> 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.
> 
> 
> Alternatives considered
> 
> 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.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/0e2445b4/attachment.html>