# Add accessor with bounds check to Array **URL:** \ **Category:** Pitches\ **Tags:** collection\ **Created:** [October 10, 2018, 8:12pm UTC](https://forums.swift.org/t/add-accessor-with-bounds-check-to-array/16871 "2018-10-10T20:12:08Z")\ **Posts on this page:** 1\ **Showing post:** 35
**Author:** ![jarod](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jarod/32/364_2.png) [@jarod](https://forums.swift.org/u/jarod)\ **Post date:** [October 26, 2018, 9:25pm UTC](https://forums.swift.org/t/add-accessor-with-bounds-check-to-array/16871/35 "2018-10-26T21:25:10Z")
> [@Jens](#): > > But I think `values[safe: index]` is as bad as `values[checked: index]` . The term "safe" is used to describe the language ( _Swift makes it easy to write software that is incredibly fast and safe by design._ ), hence Swift's regular array subscript has been designed to be _safe_ (by trapping if its out of bounds check fails), and it's also used consistently afaics in the language for things like `UnsafePointer` , `unsafeBitCast` , `unsafeDowncast` , `withUnsafeBytes` , etc, just like the term "(un)checked" is consistently used, in eg: > > ```swift > let a = Range(uncheckedBounds: (lower: 123, upper: -1)) > print(a) // 123..<-1 > > ``` > > It would be unfortunate to introduce additional meanings of the words "(un)safe" and "(un)checked" in the language when there currently afaik is only one. Safety can be thought of in tiers -- trapping is safer than reaching into out-of-bounds memory, but returning nil is even safer than trapping, requiring the programmer to consciously deal with the optionality at the call site instead of implicitly crashing. [Swift.org - About Swift](http://swift.org/about) explicitly references optionals as a safety feature, so I don't feel that it's a stretch to call this the safer version of the API. --- _[View the full topic](https://forums.swift.org/t/add-accessor-with-bounds-check-to-array/16871)._