<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 Mar 8, 2016, at 1:09 PM, Haravikk 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 8 Mar 2016, at 15:26, Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>> wrote:</div><div class=""><br class=""><blockquote type="cite" class="">Am 08.03.2016 um 11:07 schrieb Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class="">Just because someone opts to use error handling over a failable initialiser doesn’t mean they have to go overboard on the detail of their errors; it’s entirely possible to pick a reasonable middle-ground.<br class=""></blockquote><br class="">And it is entitely possible to just use an optional. If you prefer to use error handling over failable initializers, fine, just do so, but don't force it on others who are perfectly happy with the option to use optionals, too.</div></blockquote><br class=""></div><div class="">It’s not an issue of ideology but of redundancy; the failable initialiser does nothing that error handling can’t do just as easily, the only difference is that instead of returning nil, you throw an appropriate error.</div></div></div></blockquote><div><br class=""></div><div>Are you proposing removing both “init?” and “init!” or just the former?</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">The few extra characters are hardly going to kill you, while a thrown error (with common ones available for simplicity) can describe what went wrong in more detail than just “something went wrong”. Point is that we have two ways of achieving the same goal, but error handling encourages developers to think more about what type(s) of error to throw at each point; even just simple error types with no further detail can provide more information simply by being different, for example if you have a NonNumericError vs EmptyStringError types, the errors themselves tell you all you’re likely to need to know (hopefully there’d be a good set of common types).</div><div class=""><br class=""></div><div class="">There are also some cases where failable initialisers can have subtle errors, for example, can you tell me where I might run into problems with the following:</div><div class=""><br class=""></div><div class=""><span style="font-family: Menlo; font-size: 11px; color: rgb(187, 44, 162);" class="">struct</span><span style="font-family: Menlo; font-size: 11px;" class=""> MyType {</span></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span> elements:[<span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">String</span>]</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">func</span> asInt(index:<font color="#703daa" class="">Array<String>.Index</font>) -> <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span>? {</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">if</span> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">self</span>.<span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">elements</span>.<span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">indices</span>.<span style="font-variant-ligatures: no-common-ligatures; color: #3d1d81" class="">contains</span>(index) {</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">return</span> <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span>(<span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">self</span>.<span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">elements</span>[index])</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> }</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">return</span> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">nil</span></div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> }</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">}</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>