on Wed Apr 13 2016, Dave Abrahams <swift-evolution@swift.org> wrote:
> on Mon Apr 11 2016, Nate Cook <swift-evolution@swift.org> wrote: > >> Proposal link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md >> >> On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Thanks for your comments, Brent! >> >> on Sun Apr 10 2016, Brent Royal-Gordon >> <swift-evolution@swift.org> wrote: >> >> The shift described in this proposal is extremely valuable and makes >> implementing collections far more intuitive, as all the collection's logic >> lives >> "inside" the collection itself. My only hesitation is with the naming of the >> method that Brent also called out: >> >> ... snip ... >> >> func index(n: IndexDistance, stepsFrom i: Index) -> Index >> >> Oof, I am really not a fan of this name. `steps` is sort-of a label >> on >> the `n` parameter, but it's attached to `i`. >> >> Oof indeed! This is a very unusual method in the standard library, since >> we're >> calling on one instance to perform an action on another. My problems with the >> naming are twofold: >> >> (1) Collision with the index(of:) and index(where:) APIs >> The existing methods are used for searching a collection, possibly finding a >> matching index, possibly not. The new ones deterministically find an new >> index >> at a prescribed distance, with important and slightly complicated >> preconditions. >> These differences make the use and "flavor" of the two sets of methods >> distinct >> enough that I think they should have different names. >> >> (2) Arguments are reversed >> I think the ideal API for this would be index.advanced(by: 5, in: c), but I >> prefer keeping the index-moving implementation in the collection, not the >> index. >> I would favor any naming for this method that puts the index before the >> distance, keeping the overall shape of the advanced(by:) method. c.advance(i, >> by: 4) would be my pick. > > Dmitri, Max, and I just talked this over and we think you're right on > both counts. Having these “index” overloads appear in completion lists > alongside the ones that are there for use as high-level algorithms seems > wrong. Also, since the method either returns a modified version of the > index or modifies the index in place, the index argument is “more > primary” and should come first. Here's what we came up with: > > let j = location(i, offsetBy: 5) > > formLocation(&i, offsetBy: -2) > > Feedback welcome. Updated proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
