I’m fairly sure that MutableCollection mutations are not allowed to invalidate 
any indices (for this exact reason). It would be great if someone could confirm 
this.

> One (potentially dumb) question...
> 
> If the actual indices are needed inside the loop, presumably this means they 
> will be used in the loop, perhaps to mutate it, and if the collection is 
> mutated won't that either invalidate (or change the relative correspondence 
> of) the others indices, because the collection accessed in the loop will be 
> the mutated one whereas the indices refer to the copy that was taken at the 
> start when the 'for' statement was evaluated?
> 
> 
> 
> On Wed, 28 Sep 2016 at 19:34 Sean Heber via 
> swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > This might just be me being silly, but is there any way to be able to do 
> > something like this instead:
> > 
> > for (index, value) in sequence {
> > }
> > 
> > Maybe by adding another variant of makeIterator() that only differs by the 
> > return type or something like that?
> > 
> > I sort of dislike that enumerated() and indexed() would co-exist and 
> > potentially lead to really subtle bugs when getting them confused. 
> > Obviously removing enumerated() would be a breaking change, though, and 
> > maybe it has valuable uses that I’m not really thinking about (although it 
> > seems to me that the index/value pair is what you want like, 99% of the 
> > time and plenty of people - myself included - have been using the index of 
> > enumerated() as an array index even though that’s technically maybe not 
> > quite ‘correct').
> > 
> > l8r
> > Sean
> > 
> > 
> > >On Sep 28, 2016, at 12:55 PM, Erica Sadun via 
> > >swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > >
> > >Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
> > >
> > >Introducing indexed() collections
> > >
> > >• Proposal: TBD
> > >• Author: Erica Sadun, Nate Cook, Jacob Bandes-Storch, Kevin Ballard
> > >• Status: TBD
> > >• Review manager: TBD
> > >Introduction
> > >
> > >This proposal introduces indexed() to the standard library, a method on 
> > >collections that returns an (index, element) tuple sequence.
> > >
> > >Swift-evolution thread: TBD
> > >
> > >Motivation
> > >
> > >The standard library's enumerated() 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 an Array index 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 use enumerated()-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 introduces indexed() to produce 
> > >a more semantically relevant sequence by pairing a collection's indices 
> > >with 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 of indexed() 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 through IndexedSequence, 
> > >similar to EnumeratedSequence.
> > >
> > >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(mailto:swift-evolution@swift.org)
> > >https://lists.swift.org/mailman/listinfo/swift-evolution
> > 
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto: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