[swift-evolution] [Pitch] Adding safety to arrays

[Brent Royal-Gordon]

> On Apr 13, 2017, at 9:18 AM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
> In any case, given that we're discussing a "safe subscript", we need a way to differentiate the safe subscript from the unsafe subscript. The only two ways to do that are to either add an argument label or change the argument type, and IMHO the best alternate argument type is `Index?`, since it's pretty light-weight, already part of the stdlib, and already familiar to Swift developers.


Compiler and syntax issues aside, the real issue with using `Int?` as the type is this: If you take `Int?` as a subscript type, then someone can say `foos[nil]`. What are you going to do about that? It's obviously incorrect, so you really ought to fail a precondition, but that means you've opened a "safety" hole as bad as the original one, purely to get a nice syntax.

So, I think if you're going to do this, you need an argument label. The question then is, what label should we use?

The most common choice is `safe`, but "safe" has a specific meaning in the Swift compiler and standard library (i.e. memory safety), and we shouldn't muddy that. Instead I'll nominate `checking`, which in context reads like:

	if let foo = foos[checking: i] { … }

(But keep in mind that you shouldn't use the checking subscript in `tableView(_:numberOfRowsInSection:)` or any of the other table view delegate methods. Section and row indices should always be derived from the count of the same array you're indexing, so it should never be possible to receive an invalid section or row index in a table view delegate/data source method. If that happens, the only possible cause is programmer error, and the correct behavior when Swift code detects programmer error is to fail a precondition and trap.

I'd actually say the #1 reason not to add this feature is that a lot of developers don't seem to understand this, and they're likely to use the feature to make their code try to continue in the face of programmer error instead of trapping like it properly should. A program in an inconsistent state is dangerous; best to stop it quickly before it does some damage.)

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/1a834194/attachment.html>