# Optional safe subscripting for arrays

**URL:** <https://forums.swift.org/t/optional-safe-subscripting-for-arrays/1100>\
**Category:** Discussion\
**Created:** [January 16, 2016, 8:44pm UTC](https://forums.swift.org/t/optional-safe-subscripting-for-arrays/1100 "2016-01-16T20:44:31Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [February 6, 2016, 12:23am UTC](https://forums.swift.org/t/optional-safe-subscripting-for-arrays/1100/23 "2016-02-06T00:23:25Z")

</div>

There's a pretty big difference between "nil" and "Some(nil)" (and "Some(Some(1))"). This was covered pretty early on in the Apple Swift blog \<[Optionals Case Study: valuesForKeys - Swift Blog - Apple Developer](https://developer.apple.com/swift/blog/?id=12&gt); While double optionals can be confusing for humans, the compiler ought to pretty much always do something sensible.

…though I did say "ought to"; the compiler has done some less-than-sensible things in overload resolution before…

Jordan

> **···**
>
> > On Feb 5, 2016, at 15:58, Maximilian Hünenberger via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > You are totally right. The return type is "Int??".
> > 
> > My point was that if we allowed something like this (as suggested by Dave Sweeris I think):
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;var array: [Int?] = [1]  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[ifExists: 0] = nil
> > 
> > To set the element at index 0 to nil instead of doing nothing.  
> > The next example would also set index 0 to nil even though the getter failed:
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[ifExists: 0] = array[ifExists: 1]
> > 
> > - Maximilian
> > 
> > Am 05.02.2016 um 10:20 schrieb Haravikk \<swift-evolution@haravikk.me \<mailto:swift-evolution@haravikk.me\>\>:
> > 
> > > > On 4 Feb 2016, at 20:24, Maximilian Hünenberger via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:
> > > > 
> > > > I just realized that the normal setter for failable lookups is very nice in case of assigning/swapping:
> > > > 
> > > > > extension Array {  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;subscript(ifExists idx: Index) -\> Element? {  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;get { return (startIndex ..\< endIndex) ~= idx ? self[idx] : nil }  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;set { if (startIndex ..\< endIndex) ~= idx && newValue != nil { self[idx] = newValue! } }  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > > > > }
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// array[index1] is only set if both indexes are valid  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;array[ifExists: index1] = array[ifExists: index2]
> > > > 
> > > > if array is of type [Int?] and the special setter for optional Elements would have been added:
> > > > 
> > > > array[index1] would be set to "nil" if array[index2] is nil or index2 is not valid which is unfortunate.
> > > 
> > > Wouldn’t the return type be Int?? in this case? It’s not as pretty to test for as a plain Int? but iirc you can still distinguish a return type of nil from an optional that happens to contain nil, which should allow you to tell the difference between a nil value and an invalid index, I just can’t recall how at the moment (as I design around cases like these like my life depends on it ;)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

_[View the full topic](https://forums.swift.org/t/optional-safe-subscripting-for-arrays/1100)._