on Tue Apr 12 2016, plx <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
