This seems inconsistent to me. 2 is 2... 2 itself is not optional. You wouldn't expect 2 to be unwrapped. Best Josh
Sent from my iPhone On Apr 13, 2017, at 08:48, Jeff Kelley via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote: 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<mailto: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<mailto: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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org<mailto:swift-evolution@swift.org> https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
