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

Dmitri Gribenko gribozavr at gmail.com
Sun Apr 10 21:12:48 CDT 2016

On Sun, Apr 10, 2016 at 4:16 PM, Jacob Bandes-Storch via
swift-evolution <swift-evolution at swift.org> wrote:
> Minor questions after initial read-through:
> - Should the comment on {index,formIndex}(_:stepsFrom:) say what happens if
> the resulting index would be out of bounds?

Yes, we should make that clear.  The answer is that you get
unspecified memory-safe behavior.  We encourage implementations to
trap, but it is allowed to return an index that is invalid, and some
later use of it will trap, or return a valid index (say, equivalent to

> Can these functions return
> Optional values, or can they be `throws`?

Detecting such misuse can be too expensive, so it is not possible to
require these functions return a guaranteed indicator of failure.
Also, in most cases, producing an out-of-bounds index is a program
error, and it is not possible to recover from it.  (Imagine that you
are writing sort(), and you need to split the collection in two halves
-- what would you do if index() returns nil?)

> - Can {index,formIndex}(_:stepsFrom:) be combined with the limitedBy:
> versions, such that the limit is an optional parameter with default value
> nil? For example:
>     public func index(n: IndexDistance, stepsFrom i: Index, limitedBy limit:
> Index? = nil)

We considered it, but decided against it.  This function is a
requirement of RandomAccessCollection.  The two-argument form is
usually trivial to implement.  The three-argument form is very tricky
to implement correctly for all edge cases.  So we require the
two-argument form, and provide a default implementation for the
three-argument one.


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

More information about the swift-evolution mailing list