<div dir="ltr">To me it depends on if the function returns a value or the result of an action which may have different results not related to the value.<div><br></div><div>- The first function on an array returns a value, the first item in an array. In this case an optional makes sense as its easy to handle by returning nil since there is no value that exists at index(1)</div><div>- The subscript operator could return an optional too when we are out of bounds since the value doesn't exist.</div><div>- Having a init throw an error makes sense to me, as for complex structures and classes there are many reasons it can fail, its not that simple to say there wasn't a value (was there some internal validation that failed)</div><div>- A fetch operation for a network request would throw on the same princible (i.e was networking down?)</div><div>- However a function that just calculated a value lets say the next URL for the next page in a eBook, would probably want too return nil since all its doing is returning a value (i.e there is a next page for this book).</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b><font color="#cc0000">___________________________________</font></b></p><p><b>James⎥Head of Trolls</b></p><p><b><font color="#cc0000"><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a>⎥<a href="http://supmenow.com" target="_blank">supmenow.com</a></font></b></p><p><b><font size="2">Sup</font></b></p><p><b><font size="2">Runway East
</font></b></p><p><b><font size="2">10 Finsbury Square</font></b></p><p><b><font size="2">London</font></b></p><p><b><font size="2">
EC2A 1AF </font></b></p></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 2, 2016 at 11:44 PM, Ross O'Brien via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Mar 2, 2016 at 11:35 PM, Haravikk via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><span><div>On 2 Mar 2016, at 23:07, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></span><div><span>On Mar 2, 2016, at 1:11 PM, James Campbell via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote type="cite"><br>Given that we now have error handling and availability checks does it make sense to have Failable Initializers which date back to Swift 1.1?<br></blockquote><br></span><span>Our error handling schema (<a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#kinds-of-error" target="_blank">https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#kinds-of-error</a>) defines how error conditions are handled, and one important class of them (e.g. the "string to int" case) is best modeled as returning an optional. This works really well in practice for functions/methods in general. </span></div></blockquote><br></div><div>Could you give an example of why failable is the better fit here? To me the following two statements are identical:</div><div><br></div><div><font face="Monaco"><span style="white-space:pre-wrap"> </span>let a = FailableType()</font></div><div><font face="Monaco"><span style="white-space:pre-wrap"> </span>let b = try? ThrowableType()</font></div><div><br></div><div>Except that in the latter case the try? is more explicit about what is happening (and that it can fail), and I have the option of catching the error to find out more about what went wrong. With some optimisation it should be possible for try? to be just as efficient as a failable initialiser I think.</div><div><br></div><div>That said, the failable initialiser could have the same explicit call syntax if it required a trailing question-mark, e.g:</div><div><br></div><div><font face="Monaco"><span style="white-space:pre-wrap"> </span>let a = FailableType()?</font></div><div><br></div><div>As currently the only indicator is on the initialiser declaration itself. Still, when it comes to debugging I’ve found it very useful to force myself to use error handling instead, as it means I have to give reasons for why something failed, which can make it easier to track issues when they do arise.</div></div><br></div></div><span class="">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>