[swift-users] Why does Array subscript fail at runtime?

Jose Cheyo Jimenez cheyo at masters3d.com
Thu Jul 21 00:37:46 CDT 2016


Making Array<T> subscript access return T? or T! instead of T. The current array behavior is intentional <http://article.gmane.org/gmane.comp.lang.swift.evolution/11277>: it accurately reflects the fact that out-of-bounds array access is a logic error, and changing the current behavior would slow Arrayaccesses to an unacceptable degree. This topic has come up multiple <http://thread.gmane.org/gmane.comp.lang.swift.evolution/3651> times <http://thread.gmane.org/gmane.comp.lang.swift.evolution/19793> before <http://thread.gmane.org/gmane.comp.lang.swift.evolution/21420>, but is very unlikely to be accepted.

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>


> On Jul 20, 2016, at 9:07 PM, H. Kofi Gumbs via swift-users <swift-users at swift.org> wrote:
> 
> Hello Swift community,
> 
> Here's a philosophy I've struggled with since I started learning Swift. In general, it seems that failable function calls return `Optional`s; however, `Array`s violate this rule by failing fast at runtime. I understand that subscripts can't throw, so the only way to fail fast is to do so at runtime. I also realize that there are many implementations of the `array[safe: index]` that I could choose to use instead. However, I do not understand why the default behavior is still to fail at runtime. Especially given how they are often introduced as a beginner-friendly data structure. Am I missing some language philosophy or major decision?
> 
> Thanks
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160720/ee09fd17/attachment.html>


More information about the swift-users mailing list