> 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.

> 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.

> 
> -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

Reply via email to