<div dir="ltr"><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">+ IntMax.max </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 12:07 PM, Greg Parker via swift-evolution <span dir="ltr"><<a href="mailto: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"><span class=""><br><div><blockquote type="cite"><div>On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_5708029127790371104Apple-interchange-newline"><div><div dir="auto"><div><span></span></div><div><div></div><div>Hi again everyone!</div><div><br></div><div>Now that Swift 4 Stage 2 proposals are being considered, I thought it might be time to revisit this proposal and see if it might align with the goals set forth for Swift 4.</div><div><br></div><div>As a quick tl;dr, this proposal describes a new "factory initializer" that would allow you to return a value from an initializer. This would have several benefits, as mentioned in the proposal itself as well as throughout this mailing list. For convenience, here's a link to the proposal on GitHub: <a href="https://github.com/rileytestut/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md" target="_blank">https://github.com/<wbr>rileytestut/swift-evolution/<wbr>blob/master/proposals/NNNN-<wbr>factory-initializers.md</a></div><div><br></div><div>Would love to hear any more comments on this proposal, and if we feel this is appropriate for considering for Swift 4 I'll happily re-open the pull request!</div></div></div></div></blockquote><br></div></span><div>"As for overriding, just like convenience initializers, factory initializers should not be able to be overridden by subclasses."</div><div><br></div><div>This needs more explanation. It is allowed for a subclass to implement a convenience initializer that has the same signature as a superclass convenience initializer or a superclass designated initializer. The convenience-over-convenience case is not technically overriding, but it is misleading to say only that a convenience initializer cannot be overridden. Do factory initializers follow exactly the same rules here as convenience initializers?</div><div><br></div><div>In addition: designated initializers and convenience initializers have rules about which other initializers can be called from an implementation. These rules are intended to guarantee that the chain of designated initializers is called correctly. What are the precise rules for factory initializers calling other initializers? What are the precise rules for non-factory initializers calling factory initializers?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>-- </div><div>Greg Parker <a href="mailto:gparker@apple.com" target="_blank">gparker@apple.com</a> Runtime Wrangler</div><div><br></div><div><br></div></font></span></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>