<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 3 Mar 2016, at 08:07, Patrick Pijnappel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Returning an optional is a <font size="2" class=""><span style="background-color:rgba(255,255,255,0)" class="">simplified </span></font>form of returning an error when there is only one straightforward way of failing. This is a very common case and is simpler than using an error, for which you need to: 1) call w/ try? 2) add 'throws' to the function 3) return some kind of error instance of some type</div></div></blockquote><br class=""></div><div>How common is it really though? I hardly ever see it come up, but maybe I’m the one doing something unusual?</div><div><br class=""></div><div>For me, checking what the return value of an initialiser is is kind of strange to me, as I just expect it to be an instance of whatever type I asked for. Error handling forces you to do something about the possibility of a failure.</div><div><br class=""></div><div></div><div><div class=""></div></div><blockquote type="cite" class=""><div>On 2 Mar 2016, at 23:44, Ross O'Brien <<a href="mailto:narrativium+swift@gmail.com" class="">narrativium+swift@gmail.com</a>> wrote:</div><div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">At the risk of appearing glib or naive - which isn't my intention, I'd like to know the answer - is there not a similar argument to be made for any function which returns an optional instead of throwing a more descriptive error? Asking an array for its first element returns an optional because of the possibility it might have no elements in it; should this throw an error instead of being 'failable’?</div></div></div></blockquote><br class=""><div class="">An optional to me represents something perfectly normal and expected happening that just has no result; i.e- in the case of an array it’s perfectly fine for it to contain no elements, so looking at the first one can’t return a concrete result.</div><div class=""><br class=""></div><div class="">This differs from using a subscript into the array with an invalid index, as with Swift’s index type model you’re not supposed to retain invalid indices into an array that has changed (a lot of the methods of Array specifically state that they disassociate indices with respect to self). So attempting to use a subscript to get an element that doesn’t exist means you’re using an invalid index you shouldn’t have retained, so an error makes sense in that case, vs. returning nil. I admit it’s an easy one to forget since Array indices are just Ints, but they could just as easily be of type ArrayIndex, so you really should limit yourself to index-specific features such as .predecessor(), .successor(), .advancedBy(), .distanceTo() and comparisons with startIndex and endIndex.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I dunno, it’s not a critical thing to change perhaps, but to me a failable/nilable initialiser doesn’t represent a failure as explicitly as error handling does, it also doesn’t force a developer using it to handle that error (even if it’s just to pop a try? in front) or force developer creating it to give a reason why the failure occurred.</div></body></html>