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

[Jeff Kelley]

Apologies if this has been suggested before, but going off of Andrew’s message, a simple syntax could be to use our existing Optional syntax:

let array = ["foo", "bar", "baz"]

let first = array[0] // type is `String`
let third = array[2?] // type is `String?`, value is .some("baz")
let fourth = array[3?] // type is `String?`, value is .none

Jeff Kelley

SlaunchaMan at gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>
> On Apr 13, 2017, at 8:19 AM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Apr 13, 2017, at 3:56 AM, Andrew Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Recently I’ve been considering the lack of safety around array indexes. Swift is designed with safety in mind, so this example would not compile:
>> 
>> var myString: String? = “hello”
>> myString.append(“ world!”)
>> 
>> The string is optional, not guaranteed to exist, so the last line requires a “!” to force-unwrap it.
>> 
>> 
>> 
>>     public func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
>>         let section = self.sections[section]
>>         
>>         return section.items.count
>>     }
>> 
>> In this example, we could provide a section number that goes beyond the bounds of the self.sections array, without any warning.
>> 
>> My suggestion is perhaps arrays should by default return an optional when given an index, and of course they’d support forced-unwrapping too. So you could then do this:
>> 
>>     let section = self.sections[section]
>>     if section == nil {
>>         return 0
>>     } else {
>>         return section!.items.count
>>     }
>> 
>> Or you could do this:
>> 
>>     let section = self.sections[section]!
>>     
>>     return section.items.count
>> 
>> Of course this would be less convenient in a lot of cases, but this is the 1 place where apps seem to encounter a crash, crashing for the same reason that’s especially avoided across most of the rest of Swift.
> 
> My understanding is that we need the current behavior to meet performance goals. We’ve discussed adding a “safe” subscript before, but the discussion usually fizzles out when no clear winner for the argument label emerges.
> 
> - Dave Sweeris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/554cea16/attachment-0001.html>