<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 Jan 10, 2016, at 7:44 PM, Matthew Johnson 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=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I have always considered the Flexible Memberwise Initialization proposal to be just a first step (as evidenced by the many future enhancements it discussed). Its review has inspired new ideas and helped to shape my vision of the best long-term solution. My final thoughts about the review can be found here: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/006176.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/006176.html</a></div><div class=""><br class=""></div><div class="">Partial initializers is the second in a series of three proposals describing general features that can work together to form a complete solution.</div><div class=""><br class=""></div><div class=""><div class="">The proposal drafts can be found at the following links:</div><div class=""><br class=""></div><div class="">* <b class="">Parameter forwarding:</b> <a href="https://github.com/anandabits/swift-evolution/blob/parameter-forwarding/proposals/NNNN-parameter-forwarding.md" class="">https://github.com/anandabits/swift-evolution/blob/parameter-forwarding/proposals/NNNN-parameter-forwarding.md</a></div><div class="">* <b class="">Partial initializers:</b> <a href="https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md" class="">https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md</a></div><div class="">* <b class="">Property lists:</b> <a href="https://github.com/anandabits/swift-evolution/blob/property-lists/proposals/NNNN-property-lists.md" class="">https://github.com/anandabits/swift-evolution/blob/property-lists/proposals/NNNN-property-lists.md</a></div></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class="">The biggest drawback I see is that is doesn’t really address the ability to use normal functions to initialize the state of the type. For example, in order to implement a “reset” or “clear” mechanism, I still need to duplicate a bunch of init code.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">class CFoo {<br class=""> private(set) var value: Int<br class=""> <br class=""> func reset() {<br class=""> value = 0<br class=""> }<br class=""> <br class=""> init() {<br class=""> // Really want to just call this...<br class=""> //reset()<br class=""> <br class=""> // But, instead, I need to duplicate the code from `reset()`<br class=""> value = 0<br class=""> }<br class=""> <br class=""> func inc() {<br class=""> ++value<br class=""> }<br class="">}<br class=""><br class="">let c = CFoo()<br class="">c.inc()<br class="">c.value // 1<br class="">c.reset()<br class="">c.value // 0<br class=""></font><br class=""></div></blockquote><div class=""><br class=""></div><div class="">Take the above code, the “init” functionality is really about putting the type in the correct state. I think I’d rather see a mechanism to make a non-initializer as adhering to the rules of an init() so that it could be used in multiple contexts. </div><div class=""><br class=""></div><div class="">I think this modification makes your proposal much more interesting and applicable to more use cases.</div><div class=""><br class=""></div><div class="">-David</div></body></html>