<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">These are good points to bring up, Dennis. I'm not one of the standard library authors, so I might not get this exactly right, but I'll try to address each point.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 14, 2015, at 15:40, Dennis Lysenko <<a href="mailto:dennis.s.lysenko@gmail.com" class="">dennis.s.lysenko@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Jordan, I think the inspiration here might come from Ruby. I must admit that seeing that `Array.first` returns an optional, but Array#subscript raises a runtime error when the index is out of bounds threw me for a loop. In Ruby, both Array#first and Array.subscript return an optional.<div class=""></div></div></div></blockquote><div><br class=""></div><div>I do remember there being a discussion about this. One of the arguments in favor of the current behavior was "seq.first ?? defaultValue", which isn't too uncommon. The equivalent with an arbitrary subscript comes up much less often.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">If one of the original tenets of swift was to provide greater compile-time null-safety, which it definitely seems it was given the commendable emphasis on optionals being easy to use, then returning an optional would be a solid way to go about subscripting. Think of it this way: when I call a method with nullable return value, I am forced to deal with the fact that the method can fail at compile time. When I subscript an array, I am not forced to deal with it at compile time, and it will fail at runtime instead.</div><div class=""></div></div></div></blockquote><div><br class=""></div><div>From my perspective, array subscripting is not "an operation that can fail". It just has a precondition on its input parameter. Optional return values force you to deal with <i class="">dynamic</i> failures, but array subscripting should never get to that point.</div><div><br class=""></div><div>I think the equivalent would be forcing the user to check the <i class="">input</i> rather than the <i class="">output,</i> just as you are forced to check whether an optional is nil <i class="">before</i> using it rather than <i class="">after.</i> If you ignore a method return value you're not actually dealing with its failure.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Nullable subscripting is a big departure from the way most modern languages do things and that is why I don't blame you for rejecting it. That said, it is a pleasant change in the way you think about subscripting.</div><div class=""><br class=""></div><div class="">As a closing thought, subscripting hashes returns an optional value. You might consider this a pretty big inconsistency with arrays. Let me flip your argument against optional array subscripting, for dictionaries: <span style="line-height:1.5" class=""><b class="">When you are performing a subscript where the key is out of the key set, is it not a programmer error?</b></span></div></div></div></blockquote><div><br class=""></div><div>No, it is not; it is the canonical way to tell if a key has an entry in the dictionary, and the canonical way to insert a new entry into the dictionary. The same is not true for Array.</div><div><br class=""></div><div>(Note also that Dictionary's subscript that takes an Index does not return an optional result.)</div><div><br class=""></div><div>Jordan</div></div></body></html>