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

[Douglas Gregor]

> On Feb 11, 2016, at 9:12 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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>
This specific proposal is a non-starter for me, because it lands squarely in the "death valley" of being extremely invasive on the implementation while providing only a small amount of relative value.

Swift’s implementation—from semantic analysis through SIL and the runtime—assume that the only types that can conform to protocols are so-called “nominal” types, which have names that are meaningful in the runtime. Swift’s nominal types are structs, classes, enums, and protocols. Compound types such as functions, tuples, and protocol compositions, as well as aliases of types (typealiases), are not nominal. It is absolutely possible to generalize Swift’s implementation to deal with non-nominal types that conform to protocols, but it is going to be a significant amount of work across the compiler and runtime. That work is way out of scope of Swift 3, and needs to be justified by major improvements to the language.

Making some class of tuples conform to CollectionType isn’t a big enough justification. Giving me the ability, as a user, to extend tuple types to make them conform to a particular protocol myself might be big enough. For example, if I combined that with some kind of variadic generics, parameterized extensions, and conditional conformances, I could express “make any tuple of Hashable types Hashable”:

extension<T... where T : Hashable...> (T...) : Hashable {
  var hashValue: Int {
    return combineHash(self.hashValue...)
  }
}

I’m appropriating the syntax of C++11 variadic templates for this example, but essentially ’T’ is acting as a bunch of separate type parameters that can be expanded into separate type arguments with “T…”. While the syntax doesn’t matter so much, there is significant user-level impact here: one could use tuples as keys of a Dictionary or elements of a Set, make tuples conform to protocols for serialization, and so on.

	- Doug

> 
> 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/c90f6586/attachment.html>