+1 for `indexed()`, but I’m not sure about `IndexedSequence`. Why not `IndexedCollection`, which could also conform to Collection? With conditional conformances to BidirectionalCollection and RandomAccessCollection. This wouldn’t penalise the performance with respect to a simple `IndexedSequence`, would it?
> Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2 > > Introducingindexed()collections > Proposal: TBD > Author:Erica Sadun(https://github.com/erica),Nate > Cook(https://github.com/natecook1000),Jacob > Bandes-Storch(https://github.com/jtbandes),Kevin > Ballard(https://github.com/kballard) > Status: TBD > Review manager: TBD > > Introduction > > This proposal introducesindexed()to the standard library, a method on > collections that returns an (index, element) tuple sequence. > > > Swift-evolution thread:TBD(https://gist.github.com/erica/tbd) > > Motivation > > The standard library'senumerated()method returns a sequence of pairs > enumerating a sequence. The pair's first member is a monotonically > incrementing integer starting at zero, and the second member is the > corresponding element of the sequence. When working with arrays, the integer > is coincidentally the same type and value as anArrayindex but the enumerated > value is not generated with index-specific semantics. This may lead to > confusion when developers attempt to subscript a non-array collection with > enumerated integers. It can introduce serious bugs when developers > useenumerated()-based integer subscripting with non-zero-based array slices. > > > Indices have a specific, fixed meaning in Swift, which are used to create > valid collection subscripts. This proposal introducesindexed()to produce a > more semantically relevant sequence by pairing a collection'sindiceswith its > members. While it is trivial to create a solution in Swift, the most common > developer approach shown here calculates indexes twice: > > extension Collection { /// Returns a sequence of pairs (*idx*, *x*), where > *idx* represents a /// consecutive collection index, and *x* represents an > element of /// the sequence. func indexed() ->Zip2Sequence<Self.Indices, > Self>{ return zip(indices, self) } } > > Incrementing an index in some collections can be unnecessarily costly. In a > lazy filtered collection, an index increment is potentially O(N). We feel > this is better addressed introducing a new function into the Standard Library > to provide a more efficient design that avoids the attractive nuisance of the > "obvious" solution. > > Detailed Design > > Our vision ofindexed()bypasses duplicated index generation with their > potentially high computation costs. We'd create an iterator that calculates > each index once and then applies that index to subscript the collection. > Implementation would take place throughIndexedSequence, similar > toEnumeratedSequence. > > Impact on Existing Code > > This proposal is purely additive and has no impact on existing code. > > Alternatives Considered > Not yet > > > > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
