[swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Nevin Brackett-Rozinsky]

+1, I have been mildly surprised that this was not already present.

My workaround heretofore has been:

for idx in abc.indices {
  let val = abc[i]
  // do something with idx and val
}

Nevin


On Wed, Sep 28, 2016 at 1:55 PM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
>
> Introducing indexed() 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
>
>
> <https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2#introduction>
> Introduction
>
> This proposal introduces indexed() 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>
> <https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2#motivation>
> 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.
>
> <https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2#detailed-design>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.
>
> <https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2#impact-on-existing-code>Impact
> on Existing Code
>
> This proposal is purely additive and has no impact on existing code.
>
> <https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2#alternatives-considered>Alternatives
> Considered
> Not yet
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160928/e8ebe0f8/attachment.html>