<html><head></head><body><div>Just to iterate returning an optional as an error I still think is fine for normal functions.</div><div><br></div><div>But for the reasons I outlined above I think it's problematic for inits.</div><div><br></div><div>Of course two simpler ways towards solving it would to have a guide to explain best practice of when to use fallible init vs a throw.</div><div><br></div><div>Also all falliable inits perhaps should have ? In their name (and maybe functions who return one too) Or at least be allowed to give the function a name with ? In it.</div><div><br></div><div>In Ruby ? And ! Were nice explicit ways of saying this returns a Bool or this does something dangerous. Having this in swift or something like it would be a great way of making optional functions easier but I'm not sure how desirable this is.</div><div><br></div><div>Hence my original proposal is just limited to inits where unexpected errors are far more likely to occur than a function.</div><div><br><div class="acompli_signature">Sent from <a dir="ltr" href="http://supmenow.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="0">Supmenow.com</a></div><br></div><br><br><br>
<div class="gmail_quote">On Thu, Mar 3, 2016 at 12:07 AM -0800, "Patrick Pijnappel via swift-evolution" <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="3D"ltr"">
The error handdling model as described in <a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#kinds-of-error">https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#kinds-of-error</a> is very sensible and consistently applied throughout the language.<div><br></div><div>Returning an optional is a <font size="2"><span style="background-color:rgba(255,255,255,0)">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></div><div><br>On Thursday, 3 March 2016, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>The reasoning for me is that they help describe the difference between a function that can return a nil value as part of it's normal operation and a function that can encounter an unexpected error.</div><div><br>On 03 Mar 2016, at 00:44, Ross O'Brien via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><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">On Wed, Mar 2, 2016 at 11:35 PM, Haravikk via swift-evolution <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','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 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="javascript:_e(%7B%7D,'cvml','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="javascript:_e(%7B%7D,'cvml','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>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','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></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></div>
</div>
</blockquote>
</div>
</body></html>