I’m aware, which is why I didn’t say it should be removed. (And if I hadn’t been aware, this wouldn’t have helped me discover them. :-)
> On Sep 28, 2016, at 8:58 PM, Kevin Ballard <ke...@sb.org> wrote: > > There's more uses for enumerated() than just producing Array indices. > > -Kevin > > On Wed, Sep 28, 2016, at 05:49 PM, Colin Barrett via swift-evolution wrote: >> Definitely well motivated. It seems like having both .enumerated() and >> .indexed() methods would still leave open the possibility of novices using >> .enumerated and making the same mistake as before. I realize that because of >> where .enumerated() sits it has to work the way it does, but is there >> perhaps a better design (with constrained extensions?) for a single method >> that can give an Int for a Sequence and an appropriate Index for a >> Collection? >> >> -Colin >> >>> On Sep 28, 2016, at 1: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 >>> <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@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 >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
