[swift-evolution] [RFC] New collections model: collections advance indices

Dmitri Gribenko gribozavr at gmail.com
Wed Mar 2 03:21:58 CST 2016

On Wed, Mar 2, 2016 at 1:08 AM, Brent Royal-Gordon
<brent at architechies.com> wrote:
>> We would like to propose a major change to how collection indices
>> work.  The standard library team has discussed this idea internally
>> and we wrote a prototype.  Now we think it is a viable direction to
>> consider, and we are bringing it for wider public discussion.
> This is super-interesting, and overall I think it's probably an improvement (although I haven't gone *really* deep with generic CollectionType code very often).
> I do have a question, though it may simply betray my ignorance. `advance` has two forms:
>         func advance(i: Index, by n: IndexDistance) -> Index
>         func advance(i: Index, by n: IndexDistance, limit: Index) -> Index
> This is a pretty straight port of the old `advance`:
>         public func advancedBy(amount: Distance) -> Self
>         public func advancedBy(amount: Distance, limit: Self) -> Self
> But I'm not sure the `limit` parameter is still appropriate. I've always figured that you were supposed to pass the collection's `endIndex` there, but now that `advance` *is* a method on the collection, it can access that itself. Would we be better served with something like this?
>         func unsafeAdvance(i: Index, by n: IndexDistance) -> Index              // no endIndex check
>         func advance(i: Index, by n: IndexDistance) -> Index                    // endIndex check
> Or do you imagine the `limit` parameter being put to some other use that I'm not thinking of?

If limit was implied to be endIndex, how would Slice implement the
limiting advance?  Only by ignoring the advance() implementation from
the collection, and incrementing manually.  So it seems like advance
with an explicit limit is a basic operation that you can use to build

Another thing is that 'unsafeAdvance' is not really unsafe, it used to
be implementation-defined, but not memory-unsafe.  But now that the
collection is always available in advance(_:by:), we should be able to
require it to perform a trap if result is out of bounds.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-evolution mailing list