<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">As the review of the Flexible Memberwise Initialization proposal draws to a close I would like to offer some final thoughts. </div><div class=""><br class=""></div><div class="">First, I would like to thank everyone who has reviewed the proposal and participated in the discussion. You have all given me a lot to think about. I believe this discussion has been very productive. It has helped to move my thinking on the topic forward and shape a more complete, more compelling vision of where we can go.</div><div class=""><br class=""></div><div class="">At a high level I think there are a few takeaways. </div><div class=""><br class=""></div><div class="">First, there seems to be very broad (but not universal) agreement that something should be done to make trivial initialization code more concise. The problem is worth solving.</div><div class=""><br class=""></div><div class="">Second, there is more support than opposition for this proposal, but the response is definitely mixed. By my tally the responses are roughly:</div><div class=""><br class=""></div><div class="">55% favorable (Chris and I are both still favorable)</div><div class="">20% mixed</div><div class="">25% opposed</div><div class=""><br class=""></div><div class="">The categorization is somewhat subjective but I believe anyone who does a tally on their own will come up with reasonably similar results.</div><div class=""><br class=""></div><div class="">Third, there are some common and valid criticisms which are addressed further down below.</div><div class=""><br class=""></div><div class="">Finally, I after much vetting I still believe this proposal does a good job of fulfilling the goal it set out to do, namely improve the existing memberwise intializer by making it much more flexible. </div><div class=""><br class=""></div><div class="">Even several of those who oppose the proposal have agreed with that. The basis of their opposition is that once you work out the details of doing so the resulting complexity is not worth it. </div><div class=""><br class=""></div><div class="">Personally, I believe the increase in complexity over the current implicit memberwise initializer is not as significant as some perceive and the additional flexibility more than pays for the cost of the incremental complexity. The changes from current state can be summarized concisely as:</div><div class=""><br class=""></div><div class="">1. Allow the memberwise initializer to be used in classes</div><div class="">2. Allow default parameter values for `var` properties</div><div class="">3. Fix the problem the current memberwise initializer has with lazy properties</div><div class="">4. Use the `set` rather than `get` visibility for `var` properties</div><div class="">5. Allow you to request the memberwise initializer, including:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>i. Add additional parameters</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>ii. include an initializer body</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>iii. Specify access level, which will result in omission of memberwise parameters for more-private properties (it would be reasonable to limit this to private and internal if concerns about allowing it to be public are a significant factor)</div><div class=""><br class=""></div><div class="">The perceived complexity of this proposal focuses on the property eligibility rules. As noted in the list above, there are only two differences in those rules under the curernt proposal compared to the existing implicit memberwise initializer: #4 and #5.iii. In exchange for accepting those two changes this proposal gives us the increased functionality in the rest of the list.</div><div class=""><br class=""></div><div class="">Despite the proposal doing a good job of fulfilling the basic goal, there have been some very valid critiques of it:</div><div class=""><br class=""></div><div class="">1. **Complexity:** the rules of any workable automatic model are inherently nontrivial. </div><div class="">2. **Limitations:** it isn't possible to specify an explicit list of parameters, their order, their external lablels, and default values for `let` properties. </div><div class="">3. **Specificity:** the memberwise initialization is a very special case feature. It would be better to have more general facilities that support the memberwise initialization use case.</div><div class=""><br class=""></div><div class="">I have been giving a lot of thought to all of them. I espicially want to thank Dave Abrahams and Joe Groff for starting the discussion around looking for more general facilities to support memberwise initialization. </div><div class=""><br class=""></div><div class="">Ultimately, improving the existing memberwise initializer is not the best premise for a long-term solution to address the limitations of this proposal. A solution built on more general features can be just as clear and expressive, while also serving use cases beyond memberwise initialization.</div><div class=""><br class=""></div><div class="">With all of the above in mind, my recommendation is to accept this proposal and simultaneously keep working on more general facilities that can supercede the faciilities of this proposal (aside from the imiplicit memberwise initializer). I make this recommendation for the following reasons:</div><div class=""><br class=""></div><div class="">1. This proposal improves the implicit memberwise initializer which will not be touched by proposals for more general features adressing.</div><div class="">2. There is no guarantee that more general features addressing memberwise initialization will make it into Swift 3. Accepting this proposal guarantees we will see improvements that I believe are worthwhile, even if they are not a final solution.</div><div class="">3. Implementation could begin with an eye on the more general approach, possibly providing a head start on implementing them.</div><div class=""><br class=""></div><div class="">I would also like to begin discussion regarding three general facilities that can work together to improve the conciseness and expressiveness of our initializers. The combination of the first two facilities can supercede the functionality of this proposal. I believe all three facilities working together can signficantly increase the clarity and expressiveness of our initialization code. </div><div class=""><br class=""></div><div class="">1. <b class="">Parameter forwarding:</b> I began working on a general purpose parameter forwarding proposal prior to this review. This feature will add clarity to various forms of chained initializers. It will also be to any function that needs to forward a set of arguments from its caller directly to another function, not just to initializers.</div><div class=""><br class=""></div><div class="">2. <b class="">Partial initializers:</b> The idea for this proposal was inspired by thinking about Joe's example of a more general solution. Using a setter to perform initialization (especially of `let` properties) just seems wrong to me. What we need is a partial initializer which can be used to factor out common initialization logic. Partial initialzers are a general purpose initialization tool, not a tool specific to memberwise initializers. However, when combined with parameter forwarding and a few implicit partial initializers, it is possible to replace the explicit memberwise initializers described in this proposal with syntax that is just as concise.</div><div class=""><br class=""></div><div class="">3. <b class="">Property lists:</b> Property lists were inspired by two subthreads of this review. One was Joe's idea for a computed "members" tuple property. The other is all of the discussions related to limitations and lack of control in the Flexible Memberwise Initialization proposal. Property lists are a declaration that allows a user to declare a specific set of properties, in a specific order, with specific labels and specific default parameter values. This declaration results in a synthesized partial initializer as well as a synthesized computed tuple property. It may also synthesize other memberwise features in the future as new ideas for them arise. The property list enables extremely concise yet expressive declarations of memberwise partial initializers. It is also possible to include several implicit property lists such as `members`, `vars`, `lets`, etc which would be quite similar to some of the ideas discussed in the review thread.</div><div class=""><br class=""></div><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 class=""><br class=""></div><div class="">They contain enough detail about the proposed solution that I believe they are ready for a first round of discussion, however none are complete drafts. I will be starting a thread for each proposal. Please move discussion specific to each proposal into its respective thread.</div><div class=""><br class=""></div><div class="">Any discussion pertaining to memberwise intitialization, how these proposals address concerns brought up during the review, how well these proposals together provide a good long-term direction for memberwise intialization, etc can remain in one of the threads about the current proposal.</div><div class=""><br class=""></div><div class="">I want to thank you all again for participating. I'm very much looking forward to continuing the discussion.</div><div class=""><br class=""></div><div class="">Matthew</div></body></html>