<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="">Hello.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>class AClass {</font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init() throws {</font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// initialize and throw error when failed</font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><br class=""></font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let anInstance = try? AClass()</font></div><div class=""><br class=""></div><div class="">And you can get the reason why the initialization was failed to guide your following recovering by using codes below, which is not able to be done with failable initializer:</div><div class=""><br class=""></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>do { </font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let anInstance = try AClass()</font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>} catch let error {</font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// recover from the error</font></div><div class=""><font face="Menlo" style="font-size: 14px;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><br class=""></div><div class="">Probably the heaviest impact to current code done by removing failable initializer is the consequential changes of NSCoding protocol’s designated initializer.</div><div class=""><br class=""></div><div class="">As NSCoding protocol defines a designated initializer which unarchives the object graph from the archived data which could be invalid (by a wrong treating during a previous encoding), expired (by a software upgrade) or corrupted (by a disk error or user corrupting), the initialization might be failed respectively. But according the Objective-C’s design, such a failure is implicit and no error info would be thrown. So for NSCoding defined initializers implemented in Objective-C, it should add a default error to them when bridging them to Swift if the failable initializer was removed and the designated initializer in NSCoding was re-defined with an initializer throws error info.</div><div class=""><br class=""></div><div class="">How do you guys think of that?</div><div class=""><br class=""></div><div class="">Thanks for reading.</div><br class=""><div class="">
WeZZard
</div>
<br class=""></body></html>