<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 8, 2016, at 5:18 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</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, Matthew. (Hi, everyone.) Thanks for putting together a detailed and well-thought-out proposal. I had some smaller comments:</div></div></div></blockquote><div><br class=""></div>Hi Jordan, thanks for your review. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">- Given that these initializers are based on access control, is "public memberwise init(...)" different from "internal memberwise init(...)"? Can I put <i class="">both</i> in the same type?</div></div></div></blockquote><div><br class=""></div><div>If you have at least one internal property they would result in different signatures so would not be a duplicate declaration. The public memberwise init would obviously need to initialize the internal property somehow.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">- Why not just put the "memberwise" in the parameter list, and drop the decl modifier? This came up in the draft discussion but I didn't see any follow-up.</div></div></div></blockquote><div><br class=""></div><div>Good question. The decl modifier was initially Chris’s idea and it seemed reasonable to me so I ran with it.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">- I kind of agree now that "memberwise" is the wrong name, but I don't have a better one.</div></div></div></blockquote><div><br class=""></div><div>It is a bit verbose, and in many ways has the same issues as `associatedtype`. I used it because it is the terminology in use in Swift today and also don’t have anything better to replace it with.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">…but after reading through the formal review discussion, I have to say <b class="">I don't think this is a good feature for Swift.</b> I tend to agree with David Owens and others that this is too much magic in one keyword. (I picked David because I think his responses most closely match my concerns out of the dissenters.)</div><div class=""><br class=""></div><div class="">Imagine trying to explain this feature in <i class="">The Swift Programming Language.</i> It starts off very simple with the perfect use case:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">public struct Point {</div><div class=""> public var x: Double</div><div class=""> public var y: Double</div><div class=""> public memberwise init(...) {}</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">…but then spends the rest of the chapter going over everything in the proposal: why you can't provide a default for 'let' properties, why hiding a setter affects the presence of a member, and what to do if you want to change it but preserve backwards binary compatibility. It seems like a big, complicated feature that "does what you mean" only when it's first added and then becomes an impediment to any later change.</div></div></div></blockquote><div><br class=""></div><div>I can certainly sympathize with this. It is the big drawback of the automatic model. At the same time, this proposal builds on the existing memberwise init for structs and doesn’t really make the rules that much more complex. But it does make the feature more prevalent and visible, thus making it more important to understand the rules. And of course it could be argued that the current memberwise init is too complex as it is.</div><div><br class=""></div><div>For the record, here is a concise list of how this proposal expands the current memberwise init:</div><div><br class=""></div><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=""><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><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><div><br class=""></div><div>I am curious to hear your thoughts on which of these points are not desirable, and what your opinion is about the existing rules for the implicit memberwise init for structs.</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">I'm motivated to solve the tiny value struct case, the public C-like struct case, but I don't think I want this creeping into the interface of a public class. I'd rather go with the "annotation on parameters" solution (which would be a separate proposal, of course).</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">public struct Point {</div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> public var x: Double</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> public var y: Double</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> public init(self x: Double, self y: Double) {}</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">}</blockquote><div class=""><br class=""></div><div class="">or</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""> public init(@assigned x: Double, @assigned y: Double) {}</div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> public init(self.x: Double, self.y: Double) {}<br class=""> // something else</blockquote><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>I’ll ask you the same question I asked David about this approach: if the parameter must be explicitly related to a property for assignment, why should we repeat the type information (and default value information if it is a var)? Doesn’t it seem reasonable to omit the type?</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">For comparison with other languages, the "memberwise initializer" proposal is closest to C's brace-initialization, but C structs aren't resilient to change in the way that classes are, and they won't break if you reorder the members, while this will. The "annotation on parameters" idea is precedented in CoffeeScript, but I don't know of any other languages that do it.</div><div class=""><br class=""></div><div class="">This proposal is very practical and covers many common use cases, but I just don't see it as naturally fitting into the language.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 6, 2016, at 14:47, Chris Lattner 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=""><div class="">Hello Swift community,<br class=""><br class="">The review of "Flexible Memberwise Initialization" begins now and runs through January 10th. The proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md</a><br class=""><br class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class="">or, if you would like to keep your feedback private, directly to the review manager.<br class=""><br class="">What goes into a review?<br class=""><br class="">The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""><br class="">More information about the Swift evolution process is available at<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://github.com/apple/swift-evolution/blob/master/process.md<br class=""><br class="">Thank you,<br class=""><br class="">-Chris<br class="">Review Manager<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>