On Wed, Sep 28, 2016, at 02:02 PM, Tim Vermeulen wrote: > > > On 28 Sep 2016, at 22:57, Kevin Ballard <ke...@sb.org> wrote: > > > > 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. > > This isn’t necessarily the same though, is it? The reversed collection might > use different indices than the original collection.
Either way you write it you're dealing with reversed indices. -Kevin > >>> 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
