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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
