<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 7, 2016, at 10:03 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 11:39 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 8:28 AM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@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 dir="auto" class=""><div class="">The latter I'm afraid. <br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I was just discussing this design space with Chris Willmore, who's been working on revamping how our function type model works. If we move to a multiple-argument model for functions rather than the current every-function-takes-a-tuple-argument model, then we will likely need at least limited support for packing and unpacking tuples from and to arguments in order to avoid regressing at argument forwarding use cases. However, even that limited packing/unpacking functionality might be enough to seriously consider a more general magic "members" property as an alternative.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t mind discussing an alternative using this approach. If we’re going to do that I think it must be clear how it would cover various intended use cases in detail. Specifically, how would we address:</div><div class=""><br class=""></div><div class="">1. Default parameter values (at least for `var` properties)</div><div class="">2. `let` properties: it seems pretty magical indeed if the computed `var` property exposing the tuple could be used to initialize a `let` property.</div></div></div></div></blockquote><div><br class=""></div><div>Yeah, this member would need special initialization abilities, I agree.</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=""><div class="">3. Partial memberwise initialization exposing a subset of members following some kind of “automatic” or “opt-in” model for determining the subset.</div></div></div></div></blockquote><div><br class=""></div><div>Seems to me that could be done by factoring the interesting subsets into structs, e.g.:</div><div><br class=""></div><div>class Foo {</div><div> internal struct MemberwiseProperties {</div><div> var x,y,z: Int</div><div> }</div><div> internal var state: MemberwiseProperties</div><div><br class=""></div><div> init(members...: MemberwiseProperties.Members) {</div><div> state.members = members</div><div> }</div><div>}</div><div><br class=""></div><div>-Joe</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=""><div class=""><br class=""></div><div class="">Is it correct to assume that part of the magic is an understanding of the magic properties that allows them to be used to initialize the properties corresponding to the tuple members?</div><div class=""><br class=""></div><div class="">One thing I think is worth considering is that there is magic required no matter what approach we adopt. The primary advantage of this approach seems to be that the magic / implicit properties might sometimes be useful outside of an initialization context. There could be other advantages depending on the details of what this approach looks like but its hard to tell without more specifics.</div><div class=""><br class=""></div><div class="">Matthew</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=""><div class=""><br class=""></div><div class="">-Joe</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class="">Sent from my moss-covered three-handled family gradunza</div></div><div class=""><br class="">On Jan 6, 2016, at 7:12 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Jan 6, 2016, at 8:46 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""><br class=""><br class=""><div class="">Sent from my moss-covered three-handled family gradunza</div></div><div class=""><br class="">On Jan 6, 2016, at 5:47 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 6, 2016, at 5:23 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=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Jan 6, 2016, at 6:04 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br 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><span class="Apple-tab-span" style="white-space: pre;"> </span><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=""></blockquote><br class="">It’s okay.<br class=""><br class=""><blockquote type="cite" 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=""></blockquote><br class="">I’m lukewarm about that. I have never found writing out the initializers I want to be a significant burden, and I find my code is better when they’re explicit. Every new feature increases the language's complexity and surface area, and I fear this one is not going to pay its way.<br class=""><br class=""><blockquote type="cite" 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=""></blockquote><br class="">Yes, but I worry that it may be too early to add it. Other features in this space, like truly generic variadics, may well obsolete anything we do today. I’m not sure we should be designing convenience features that are likely to overlap with more general features coming down the road unless the inconvenience is very painful… which I personally don’t find it to be.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">It isn’t clear to me how generic variadics might obsolete the functionality of this proposal. Can you elaborate on that?</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">Not sure if this is exactly what Dave has in mind, but an idea that comes to mind: we could say that structs and classes have a magic "members" tuple and typealias:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">struct Foo {</div><div class=""> var x, y: Int</div><div class=""><br class=""></div><div class=""> // Implicit members</div><div class=""> typealias Members = (x: Int, y: Int)</div><div class=""> var members: Members {</div><div class=""> get { return (x: x, y: y) }</div><div class=""> set { (x, y) = newValue }</div><div class=""> }</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">With plausible future features for forwarding tuples as arguments, then the memberwise initializer could be implemented like this:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> // Say that a parameter declared 'x...' receives a tuple of arguments labeled according to its type,</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> // like '**x' in Python</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">init(members...: Members) {</div><div class=""> self.members = members</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">And I think all your other use cases could be covered as well.</div></blockquote><br class=""><div class="">That's exactly what I had in mind. Thanks, Joe!</div></div></blockquote><br class=""><div class="">Is there any chance of generic variadics along these lines being part of Swift 3? Or is this down the road further?</div></div></blockquote></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>