[swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dave Abrahams]

on Mon Apr 11 2016, Nate Cook <swift-evolution at 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 at swift.org> wrote:
>
>     Thanks for your comments, Brent!
>
>     on Sun Apr 10 2016, Brent Royal-Gordon
>     <swift-evolution at 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.

-- 
Dave