<div dir="ltr">My initial stance several months ago was that initializers should throw instead of returning nil, but I've changed it as a result of the error handling rationale (same document as Chris linked).<div><br></div><div>Specifically this section, taken from ErrorHandlingRationale.rst:</div><div><br></div><div><h4 style="margin-top:1em;margin-bottom:16px;line-height:1.4;font-size:1.25em;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'">Simple domain errors</h4><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px">A simple domain error is something like calling <code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;padding:0.2em 0px;margin:0px;border-radius:3px;background-color:rgba(0,0,0,0.0392157)">String.toInt()</code> on a string that isn't an integer. The operation has an obvious precondition about its arguments, but it's useful to be able to pass other values to test whether they're okay. The client will often handle the error immediately.</p><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px">Conditions like this are best modeled with an optional return value. They don't benefit from a more complex error-handling model, and using one would make common code unnecessarily awkward. For example, speculatively trying to parse a<code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;padding:0.2em 0px;margin:0px;border-radius:3px;background-color:rgba(0,0,0,0.0392157)">String</code> as an integer in Java requires catching an exception, which is far more syntactically heavyweight (and inefficient without optimization).</p><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px">Because Swift already has good support for optionals, these conditions do not need to be a focus of this proposal.</p></div><div><br></div><div>In constructors, the most common (and I would posit the only common) case of error would be a simple domain error, so failable initializers suffice.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 5, 2016 at 12:52 AM Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>+1 for keeping failable initializers. Error handling should be reserved for errors and not be used for control flow or logic.</div></div><div dir="auto"><div><br></div><div>-Thorsten </div></div><div dir="auto"><div><br>Am 27.12.2015 um 18:11 schrieb Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div>On Dec 27, 2015, at 5:22 AM, Manfred Lau via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><div><blockquote type="cite">I just found that the design of failable initializer is redundant in Swift 2. Because native error handling already has been introduced in Swift 2, and failable initializer indeed could be achieved by following codes:<br></blockquote><br></div><div>I’d be opposed to removing failable initializers. Failable inits introduce a symmetry into the language for initializers, which make them possible to do (almost) all of what you can do with a normal method. This capability is key for them to be able to replace “factory” static methods, which allows Swift to offer a consistent initialization pattern for clients of types.</div><div><br></div><div>If we forced people to use error handling for anything that could return nil, then things like String to Int conversions would most likely not use initialization syntax.</div><div><br></div><div>Besides that, over use of error handling waters it down and makes it less valuable in itself. For more information on this, please see the design discussion for error handling:</div><div><a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst" target="_blank">https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst</a></div><div><br></div><div>-Chris</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1MXK54sosN3xru3iYcLt0oBZ2w20i49gyogXctgrspd5y7yS5NzzFvD4HEj3aTB4sYwv4Rfl2YuLeMdleOEgnUi8HYCKqIjMC1fwWOZ-2Fl1vgFYrVCzWK6L0bS0QtkQqEtkcjkaMaQgOHiJRM7GxnFaBBPcAmG7NVLq2QRRWeBMxU3z2MaGgu1iT6WEyzvII5de7DJCtc-2FILHqBdREXv3FaaTSzvVRWXSOrmQ2gqupgo-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto: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>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=8CZIdLciSFC-2BO5jF-2FiP8qN7dBFsgCUZ50wdTsolcRPfuw8QWV5una1oakmGfz6e6q7lO3bZaJJpqE46LpLS47jCn0TZnM40TcOa7YMVlM0X-2Fleps-2FYSy2NTkNVQLTKW4CmRm5Jw-2BmbavXY3Tr5PPIGiGqSYu8WMCB0kGIep0zPAT7kzFI6fOqFfES9fmD4Ht38pBkat4YA3si0Sg6WangqbPmDwe13ptkGvjBpoMPH0-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
_______________________________________________<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>
</blockquote></div>