+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

Reply via email to