<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:14 AM, Joe Groff 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=""><br class=""><div class=""><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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Seems to me that could be done by factoring the interesting subsets into structs, e.g.:</div><div class=""><br class=""></div><div class="">class Foo {</div><div class=""> internal struct MemberwiseProperties {</div><div class=""> var x,y,z: Int</div><div class=""> }</div><div class=""> internal var state: MemberwiseProperties</div><div class=""><br class=""></div><div class=""> init(members...: MemberwiseProperties.Members) {</div><div class=""> state.members = members</div><div class=""> }</div><div class="">}</div></div></div></div></blockquote><br class=""></div><div>And this is more clear than this?</div><div><font face="Menlo" class=""><br class=""></font></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Menlo" class="">class Foo {<br class=""></font><font face="Menlo" class=""> var x,y,z: Int<br class=""></font><font face="Menlo" class=""> init(x: Int, y: Int, z: Int) {</font></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> self.x = x</font></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> self.y = y</font></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> self.z = z</font></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> }</font></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Menlo" class="">}</font></blockquote><div class=""><br class=""></div><div class="">It seems odd to me to change the design of your type for the sole purpose of using a language feature. </div><div class=""><br class=""></div><div class="">It’s the complexity of the feature and its applicability <i class="">only</i> to initialization that lead me to vote no for the proposal. I've wanted public, generated initializers (ask to the internal generated struct inits). However, as you dig into to see what you really need to support, the complexities become quite nuanced.</div><div class=""><br class=""></div><div class="">I keep coming back to a much simpler and more explicit desire of being able to use “self” (this is not a label, but an annotation like "inout") in the parameter list. This is applicable to <i class="">all</i> members of a type.</div><div class=""><br class=""></div><div class=""><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class="">class Foo {<br class=""></font><font face="Menlo" class=""> var x,y,z: Int<br class=""></font><font face="Menlo" class=""> init(self x: Int, self y: Int, self z: Int) {</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> // the compiler auto-inserts these lines</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> self.x = x</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> self.y = y</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> self.z = z</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> }</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""><br class=""></font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> func fooey(self x: Int) {</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> // the compiler generates</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> self.x = x</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class=""> }</font></blockquote><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class="">}</font></blockquote></div><div class=""><br class=""></div><div class="">I’m not convinced that even that is worth the magic it brings to the table, but it does get rid of nearly all of the complexities, becomes more applicable than just initialization, and has only a single rule to learn that is fairly self-explanatory. The trade-off is you must be explicit about the members of the initializer. I’m OK with that because if I have a type that really has so many members that this is a burden, then I should probably refactor it. A sufficient macro system also trivially solves this issue as well.</div><div class=""><br class=""></div><div class="">-David</div></body></html>