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
slauncha...@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@swift.org> wrote:
>
>>
>> On Apr 13, 2017, at 3:56 AM, Andrew Hart via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
