<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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div 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="">Marginally. My main concern is the complexity of the rules, especially when looking at the direction many of the futures take. There are all of these annotations that get put all over that litter the type</div></div></div></div></blockquote><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="">definition simply to support memberwise inits.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Maybe I wasn’t clear enough, but I never intended for all of them to be accepted. They are intended to show different ways to allow a bit more control.</div><div class=""><br class=""></div><div class=""><div class="">The proposal only changes current state in a few ways:</div><div class=""><br class=""></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=""><span class="Apple-tab-span" style="white-space: pre;"> </span>i. Specify access level, which will result in omission of memberwise parameters for more-private properties</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>ii. Add additional parameters</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>iii. include an initializer body</div><div class=""><br class=""></div><div class="">Are there specific changes in this list that you dislike?</div></div></div></div></blockquote><div><br class=""></div><div>No, I think you’re goal is reasonable and your proposal is well thought out. The problem comes down to the details on how to support it. Each point has a set of gotcha’s that require rules to handle properly. </div><div><br class=""></div><div>It’s simply my opinion that these rules make the feature far too complicated.</div><div><br class=""></div><div>You could go super basic and just have the proposal help address the struct scenario and have the default value for “var” members carried through to the implicitly created init(). </div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div 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="">I think it keeps coming up because it’s far simpler. While there is duplication in the type signature, the code is still smaller, more flexible, and more applicable than being limited to only initialization. Further, and I think this is what is far more important, I only need to look at single place to understand what is going on with initialization for any particular call. I don’t need to find out what members are annotated, or create the list of head of members and exclude certain ones if @nomemberize() is used. Each member being initialized as a configuration entity from the user is right there, no questions asked.</div></div></div></blockquote><div class=""><br class=""></div><div class="">How is this more applicable than just for initialization? Are you suggesting a self parameter be allowed in any method and it would result in an immediate set of that property?</div></div></div></blockquote><div><br class=""></div><div>Yes, I’m suggesting that “self” is a qualifier, like “inout”.</div><div><br class=""></div><div>This code:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><font face="Menlo" class="">struct Point {</font></div></div><div><div><font face="Menlo" class=""> var x, y, z: Int</font></div></div><div><div><font face="Menlo" class=""> init(self x: Int, self y: Int = 0, self z: Int = 0) {}</font></div><div><font face="Menlo" class=""> func foo(self x: Int) {}</font></div><div><span style="font-family: Menlo;" class="">}</span></div></div></blockquote><div><div><br class=""></div><div>Would be identical to this code:</div><div><br class=""></div><div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div><div><font face="Menlo" class="">struct Point {</font></div></div><div><div><font face="Menlo" class=""> var x, y, z: Int</font></div></div><div><div><font face="Menlo" class=""> init(x: Int, y: Int = 0, z: Int = 0) {</font></div><div><font face="Menlo" class=""> self.x = x; self.y = y; self.z = z;</font></div><div><font face="Menlo" class=""> // rest of function</font></div><div><font face="Menlo" class=""> }</font></div><div><font face="Menlo" class=""><br class=""></font></div><div><font face="Menlo" class=""> func foo(x: Int) {</font></div><div><font face="Menlo" class=""> self.x = x</font></div><div><font face="Menlo" class=""> // rest of function</font></div><div><font face="Menlo" class=""> }</font></div><div><span style="font-family: Menlo;" class="">}</span></div></div></blockquote><div></div></div><div><br class=""></div><div>That assignment happens before the function body executes.</div><div><br class=""></div><div>This model fixes the majority of my complexity issues. However, it brings some others to the table and doesn’t solve the need to duplicate all of the members in the API.</div><div><br class=""></div><div>I think something like this was mentioned before, but I don’t remember what happened with it. However, another way to do initialization could be like this (C# calls this field initializers):</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><font face="Menlo" class="">let p = Point {</font></div><div><font face="Menlo" class=""> x = 12,</font></div><div><font face="Menlo" class=""> y = 13,</font></div><div><font face="Menlo" class=""> z = 14</font></div><div><font face="Menlo" class=""> }</font></div><div><br class=""></div><div>We then get out of caring about the ordering of the parameters. However, this feature is much more narrow as it only applies to public properties. There is a lot of subtly in actually implementing this in the compiler though.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I really appreciate the feedback and conversation. I am continuing to think about all of the comments and am hoping we can come out of this review with a vision for a path forward that makes most people happy whether the proposal is accepted or not. (I think it’s clear that no solution will make everyone happy but do hope we can hit a sweet spot)</div></div></div></blockquote><div><br class=""></div><div>Just to be clear, I think the proposal lays out the land well and has good coverage of the issues. I just find it too complicated of a ruleset to need to know.</div><div><br class=""></div><div>-David</div></div></body></html>