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

[Dave Abrahams]

on Tue Apr 12 2016, plx <swift-evolution at swift.org> wrote:

> Aside: `indices` being irregular can be a benefit in the context of
> auto-complete.
>
>     * What is your evaluation of the proposal?
>
> +1, very much.
>
> As a change from the current model, it’s an across-the-board improvement for me,
> at least.
>
> In a bigger-picture sense I think Swift would be better off by going *further*
> on certain aspects, but have said all that before.
>
>     * Is the problem being addressed significant enough to warrant a change to
>     Swift?
>
> It is, again very much so.
>
>     * Does this proposal fit well with the feel and direction of Swift?
>
> Depends on the framing of the question.
>
> Compared to the previous model, it’s an unqualified YES.
>
> As a general proposition, I think this design is a local optimum for overall
> Swift-ness, but even so it’s creating a little un-Swifty pocket. It’s
> “un-Swifty” in at least two ways:
>
> # 1: Relatively Unsafe, Pointer-Like Semantics
>
> Indices—unsurprisingly!—behave quite a bit like pointers, and similarly expose
> *numerous* crashing combinations of `(value,operation)`:
>
> - self[endIndex]
> - self[startIndex] // <- when empty
> - successor(of: endIndex)
> - predecessor(of: startIndex)
>
> …etc., which is *very much* reminiscent of the hazards of pointers. (Technically
> “undefined” not “crashing”, but being realistic “crashing" is usually accurate).

No, these are unspecified in the general case, not undefined.  Unless
you're working with, e.g. `UnsafeMutableBufferPointer` (or you have a
data race), there's no undefined behavior.  The big problem with
pointers isn't what happens when they crash; it's what happens when they
*don't*.

> Although Swift uses `Optional` to mitigate the hazards of `nil` pointers (etc.),
> you’re still left to your own devices for handling indices.

`Optional` is not “mitigating hazards;” it's encoding the possibility of
null in the type system.  It's non-optional things that mitigate hazards.

> This isn’t news to anyone here, I’m sure, and may even be unavoidable; I’m just
> pointing it out as an uncharacteristically-unsafe area in Swift’s standard APIs,
> and closer to how `!` and IOUs behave than otherwise typical.

Any time there's a required relationship between two things, e.g. a
receiver and an argument, you have a precondition.  The existence of a
precondition does not make something unsafe at all in the sense that
Swift uses the term.  Safety in swift is about type and memory safety in
the absence of data races, not about having APIs that respond sensibly
to every possible combination of arguments.  Int.max + 1 will trap, but
that doesn't make addition unsafe.

Saying that it's close to how `!` behaves is not at all far from the
truth, because `!` has a precondition that its argument is non-nil.

> To help illustrate the claim, here’s a strawman “safe” API—for illustration
> only, not advocacy!—that would be safer and thus perhaps more “Swift-y”:

I think there's a prevalent misunderstanding (IOW, I don't mean to
single out this post or this poster) about what “safe” means in Swift
and what the features of a Swifty API are and should be.  This
is a big topic worthy of much more time than I can devote here, but
here's a thought to start with:

A Swifty API helps you reason effectively about the correctness of your
code, and in part that means we provide enough preconditions on
arguments to avoid complicating result types, and code to handle
results, with optional-ness.

-- 
Dave