On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote: > > > On 28 Sep 2016, at 22:46, Kevin Ballard <ke...@sb.org> wrote: > > > > That's a bunch of complexity for no benefit. Why would you ever use this as > > a collection? > > I think there is a benefit. Something like `collection.indexed().reversed()` > would benefit from that, and I think that could be useful.
Perhaps, though you could just say `collection.reversed().indexed()` instead. > > The whole point is to be used in a for loop. If it was a collection then > > you'd need to have an index for that collection, so now you have an index > > that lets you get the index for another collection, which is pretty useless > > because you could just be using that underlying index to begin with. > > Rather than introducing a new index for this, we can simply use the index of > the base collection for subscripting. That's actually a good idea, and if we do make it a collection this is probably how we should handle it. But I still argue that the ability to make something a collection doesn't mean it should be a collection, if there's no good reason for anyone to actually try to use it as such. -Kevin > > On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution wrote: > >> +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 > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
