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

[Jay Abbott]

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 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/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 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/ae567ab1/attachment.html>