<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="">How are you going to deal with public properties creating a breaking change in the memberwise init()?</div><div class=""><br class=""></div><div class="">Example:</div><div class=""><br class=""></div><div class="">v1.0 of the API ships:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">struct Person {</font></div><div class=""><font face="Menlo" class=""> let name: String</font></div><div class=""><font face="Menlo" class="">}</font></div></blockquote><div class=""><br class=""></div><div class="">v1.1 of the API ships:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">struct Person {</font></div><div class=""><font face="Menlo" class=""> let name: String</font></div><div class=""><font face="Menlo" class=""> let age: Int</font></div><div class=""><font face="Menlo" class="">}</font></div></blockquote><div class=""><br class=""></div><div class="">When you use the implicit memberwise init(), the above change is now a breaking change. There are ways around it, but all seem fragile to me - for example, requiring a default value for new properties on the declaration site.</div><div class=""><br class=""></div><div class="">Similarly, the order of the members <i class="">must</i> remain the same now, changing them is a breaking change. This is ok for structs today because the generated init() is only available within a module so all of the places that use it are limited within your own codebase.</div><div class=""><br class=""></div><div class="">This is why I do not like like the implicit behavior and the @nomemberwise attribute on the declaration of the property; it tightly couples together things that are inherently fragile.</div><div class=""><br class=""></div><div class="">-David</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 22, 2015, at 8:46 AM, 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=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Chris,</div><div class=""><br class=""></div><div class="">I have given your feedback a lot of thought and have taken another run at this proposal from a slightly different angle. I believe it is a significant improvement. </div><div class=""><br class=""></div><div class="">I believe the programmer model is now very clear straightforward:</div><div class=""><br class=""></div><div class="">The set of properties that receive memberwise initialization parameters is determined by considering only the initializer declaration and the declarations for all properties that are at least as visible as the initializer (including any behaviors attached to the properties). The rules are as follows:<br class=""><br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Their access level is at least as visible as the memberwise initializer.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• They do not have a behavior which prohibits memberwise initialization.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The property is not annotated with the @nomemberwise attribute.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The property is not included in the @nomemberwise attribute list attached of the initializer. If super is included in the @nomemberwise<br class=""></div><div class=""><br class=""></div>The parameters are synthesized in the parameter list in the location of the ... placeholder. They are ordered as follows:<br class=""><br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• All properties without default values precede properties with default values.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Within each group, superclass properties precede subclass properties.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Finally, follow declaration order</div></div><div class=""><br class=""></div><div class="">The new model has also dramatically simplified the implementation details. No more need for the compiler to scan the initializer body!</div><div class=""><br class=""></div><div class="">There are still some details present that you provided feedback on. My reply from last night is still valid discussion around those issues. Please reply inline to that message if possible. </div><div class=""><br class=""></div><div class="">I’m sure there are still plenty of details to discuss and work through, but I hope you will agree that these changes are a step in the right direction.</div><div class=""><br class=""></div><div class=""><a href="https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md" class="">https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md</a></div><div class=""><br class=""></div><div class="">Matthew</div></div></div></blockquote></div><br class=""></body></html>