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

[Dave Abrahams]

on Wed Apr 13 2016, Dave Abrahams <swift-evolution at swift.org> wrote:

> 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.

Updated proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md

-- 
Dave