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

[Nevin Brackett-Rozinsky]

I like Sean’s idea.

Nevin

On Wed, Sep 28, 2016 at 2:34 PM, Sean Heber via swift-evolution <
swift-evolution at 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 at swift.org> wrote:
> >
> > Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3
> f2
> >
> > 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 at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/128625a8/attachment.html>