<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="">Hi, Matthew. (Hi, everyone.) Thanks for putting together a detailed and well-thought-out proposal. I had some smaller comments:</div><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 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 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 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 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 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><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>https://lists.swift.org/mailman/listinfo/swift-evolution<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=""></body></html>