<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=""><div class="">If the feature were being removed, then that could be replaced by some default exception for that purpose I think?</div><br class=""><div><blockquote type="cite" class=""><div class="">On 2 Mar 2016, at 22:30, Howard Lovatt <<a href="mailto:howard.lovatt@gmail.com" class="">howard.lovatt@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Not that I personally use failable initializers, but aren't they needed to interact with Obj-C which returns nil to indicate failure from initializers?</div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"> -- Howard.<br class=""></div></div>
<br class=""><div class="gmail_quote">On 3 March 2016 at 09:27, Haravikk via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I haven’t used a single failable initialiser ever since the try! command was added, as that gave the same convenience as force unwrapping and eliminated the need for big try/catch blocks if you didn’t expect an exception, with try? likewise making it easy to detect that any exception occurred, without caring about what it was.</div><div class=""><br class=""></div><div class="">So I’d probably say that failable initialisers are unnecessary now; they’re a tiny bit cleaner for simpler failable initialisers (one type of failure), but it’s probably not worth keeping as a language feature when it comes up so rarely (at least in my experience).</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 2 Mar 2016, at 21:11, James Campbell via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">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?<div class=""><br class=""></div><div class="">Take this model</div><div class=""><br class=""></div><div class="">struct MyModel {</div><div class=""><br class=""></div><div class="">let someProperty</div><div class="">let anotherProperty</div><div class="">}</div><div class=""><br class=""></div><div class="">Lets say we have a Initializers for this structure that takes a JSON structure and returns an i.</div><div class=""><br class=""></div><div class="">We could guarantee that it always returns an instance but then we have to populate this data with dummy values if the JSON is missing values.</div><div class=""><br class=""></div><div class="">I could make these properties optional to reflect that the JSON was missing information but I would be making the structure mutable which adds complexity. On-top of that I wouldn't be able to tell if the property is nil due to a lack of a value or a bug causing certain JSON information to be missing.</div><div class=""><br class=""></div><div class="">So lets look at the alternatives with a non-guranteed system, well we have Failable Initializers. If any of the properties are missing, we should return nil.</div><div class=""><br class=""></div><div class="">Well we have this issue:</div><div class=""><br class=""></div><div class="">MyModel(json) </div><div class=""><br class=""></div><div class="">It isn't clear that this is fallable compared to a traditional initializer unless swift was update to, meaning we may forget to handle the nil case:</div><div class=""><br class=""></div><div class=""> <b class="">MyModel?(json)</b></div><div class=""><b class=""><br class=""></b></div><div class="">This isn't all that is wrong with this approach, if this method does a lot of steps to create the object and fails (Like parsing an object from JSON). Returning nil but we have no idea why, it makes it easy to introduce silently failing errors. </div><div class=""><br class=""></div><div class="">Its true some classes may do this when ran on a older version of iOS but with avaliabilty checks, this use case is irrelevant. </div><div class=""><b class=""><br class=""></b></div><div class="">So what about throwing an error?</div><div class=""><br class=""></div><div class="">It forces us to handle it failing to initialize for some reason. </div><div class=""><br class=""></div><div class="">- If we forget to handle the error, the app won't be allowed to continue with this corrupted data - and the error will be informative as it forces us to create an ErrorType.</div><div class="">- If we want to ignore this object and convert the error to nil we can still use <b class="">try? </b>(For example in a Chat application you could ignore corrupted messages).</div><div class="">- In these cases where we ignore the error using <b class="">try?</b> it makes it super obvious we are ignoring an error and it should be easy to that error causing it to fail by using <b class="">try! </b></div><div class="">- On the whole it encourages us to not return nil and to return useful error codes which we can handle, what if one of the reasons it failed to parse is something we could recover from? If we return nil we will never know.</div><div class="">- And it reduces the amount of mutability in swift.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><p class=""><b class=""><font color="#cc0000" class="">___________________________________</font></b></p><p class=""><b class="">James⎥Head of Trolls</b></p><p class=""><b class=""><font color="#cc0000" class=""><a href="mailto:james@supmenow.com" target="_blank" class="">james@supmenow.com</a>⎥<a href="http://supmenow.com/" target="_blank" class="">supmenow.com</a></font></b></p><p class=""><b class=""><font size="2" class="">Sup</font></b></p><p class=""><b class=""><font size="2" class="">Runway East
</font></b></p><p class=""><b class=""><font size="2" class="">10 Finsbury Square</font></b></p><p class=""><b class=""><font size="2" class="">London</font></b></p><p class=""><b class=""><font size="2" class="">
EC2A 1AF </font></b></p></div></div></div></div></div></div></div></div></div></div></div>
</div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>