This has been proposed before. The current implementation is intentional, as 
seen on the swift-evolution repo: 
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md#strings-characters-and-collection-types
 
<https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md#strings-characters-and-collection-types>.
 This is why: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002446.html

> 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._______________________________________________
> swift-evolution mailing list
> 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

Reply via email to