<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 2:09 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</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 8, 2016, at 11:21 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=""><div class=""><div class=""><br class=""></div><div class="">Actually it is internal, not private, and it exposes private properties via that internal initializer. It’s only in your own code, but I don't think it should be violating access control in that way.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Not for me in Xcode 7.2. Has this changed? Maybe it’s my app target? The implicit init() is only visible for me within the same file the struct is defined in.</div></div></div></div></blockquote><div><br class=""></div><div>Wow, you’re right. It is enforcing access control. The implicit init is internal if there are no private properties, but private if there are private properties. I wonder if this has changed. If not, I’m embarrassed that I didn’t understand the current behavior in detail. </div><div><br class=""></div><div>I thought it was always internal. I’ve never actually used it for a struct with private properties before and I think the docs all say internal so maybe that is why. In any case, I’m glad to see that it is enforcing access control rules.</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=""><br class=""></div><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=""><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="">The proposal essentially is doing two things:</div><div class=""><br class=""></div><div class=""> 1. Create a way to generate a public API contract based on a series of fairly complicated rules, potential annotations, and member orderings within the type</div></div></div></blockquote><div class=""><br class=""></div><div class="">Would you feel better about the proposal if it did not allow for public memberwise initializers?</div></div></div></div></blockquote><div class=""><br class=""></div><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><br class=""></div><div>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><br class=""></div><div><div>The proposal only changes current state in a few ways:</div><div><br class=""></div><div>1. Allow the memberwise initializer to be used in classes</div><div>2. Allow default parameter values for `var` properties</div><div>3. Fix the problem the current memberwise initializer has with lazy properties</div><div>4. Use the `set` rather than `get` visibility for `var` properties</div><div>5. Allow you to request the memberwise initializer, including:</div><div><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><span class="Apple-tab-span" style="white-space: pre;"> </span>ii. Add additional parameters</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>iii. include an initializer body</div><div><br class=""></div><div>Are there specific changes in this list that you dislike?</div></div><div><br class=""></div><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=""><br class=""></div><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=""><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=""> 2. Generate the pass through of assignment for the parameters of the init() and their backing values.</div><div class=""><br class=""></div><div class="">The vast amount complexity comes from trying to solve #1.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This is not true. I would still want access control enforced even if memberwise initializers could not be public.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">There’s no concern with access control as it’s explicitly handled. I can expose whatever I want as the API and route it however I want in code. </div></div></div></div></blockquote><div><br class=""></div><div>I understand that this is true with your approach. I was responding to your statement that the source of complexity in my proposal is from trying to allow public memberwise inits (your solve #1). It doesn’t come from wanting to allow public inits. It mainly comes from enforcing access control. It turns out that the current implicit init is already doing that.</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=""><br class=""></div><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=""><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="">As for this:</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><blockquote type="cite" class="">(Aside, a small nitpick, but it really bugs me: initialization has O(M+N) complexity, not O(M×N) complexity. One doesn’t initialize every member with every parameter.)</blockquote></div></div></div></div></blockquote><blockquote type="cite" class=""><br class=""></blockquote><div class=""><blockquote type="cite" class="">MxN is members x initializers.</blockquote></div></div></div><div class=""><br class=""></div><div class="">Paul, this has also bugged me too; I do not see how it is accurate. There aren’t N initializers, there is one initializer that must fully instantiate the type. Each type may have additional convenience initializers, but these are not required. Further, they cannot make use of the placeholder. There is a “futures” that talks about it, but that’s out of scope of the original proposal. </div></div></div></blockquote><div class=""><br class=""></div><div class="">Swift allows more than one designated initializer. N never large but it more than 1 in enough cases to matter. The point is that it results in enough boilerplate that I believe it affects how many people design their initializers. </div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Sure, but your base proposal does not allow a way for there to be more than one memberwise designated initializer. So in the base case, your proposal doesn’t solve what you call the MxN problem. In the futures, you describe ways to annotate inits() so that members aren’t considered in the signature.</div></div></div></div></blockquote><div><br class=""></div><div>My proposal does allow for more than 1 memberwise init. The idea is that there are different ways to init the private state. It also allows memberwise inits with different access control, which would possibly receive different memberwise parameters due to the access control rules.</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><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Menlo" class="">struct Point {</font></div></div><div class=""><div class=""><font face="Menlo" class=""> let x: Int</font></div></div><div class=""><div class=""><font face="Menlo" class=""> let y: Int</font></div></div><div class=""><div class=""><font face="Menlo" class=""> let z: Int</font></div></div><div class=""><div class=""><font face="Menlo" class=""> </font></div></div><div class=""><div class=""><font face="Menlo" class=""> @nomemberwise(y, z)</font></div></div><div class=""><div class=""><font face="Menlo" class=""> memberwise init(...) {</font></div></div><div class=""><div class=""><font face="Menlo" class=""> y = 0</font></div></div><div class=""><div class=""><font face="Menlo" class=""> z = 0</font></div></div><div class=""><div class=""><font face="Menlo" class=""> }</font></div></div><div class=""><div class=""><font face="Menlo" class=""><br class=""></font></div></div><div class=""><div class=""><font face="Menlo" class=""> @nomemberwise(z)</font></div></div><div class=""><div class=""><font face="Menlo" class=""> memberwise init(...) {</font></div></div><div class=""><div class=""><font face="Menlo" class=""> z = 0</font></div></div><div class=""><div class=""><font face="Menlo" class=""> }</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><div class=""><div class=""><font face="Menlo" class=""> memberwise init(...) {}</font></div></div></div></div><div class=""><div class=""><font face="Menlo" class="">}</font></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">Let’s say that for simplicity the @nomemberwise() attribute takes a list of parameters. This is one version of the code that can be written to support zero-ing out by default.</div><div class=""><br class=""></div><div class="">Or, we can do this (what Swift has today):</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class="">struct Point {</font></div></div></div></div><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> let x: Int</font></div></div></div></div><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> let y: Int</font></div></div></div></div><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> let z: Int</font></div></div></div></div><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> </font></div></div></div></div><div class=""><div class=""><div class=""><div class=""><span style="font-family: Menlo;" class=""> init(x: Int, y: Int = 0, z: Int = 0) {</span></div><div class=""><span style="font-family: Menlo;" class=""> self.x = x</span></div><div class=""><span style="font-family: Menlo;" class=""> self.y = y</span></div><div class=""><span style="font-family: Menlo;" class=""> self.z = z</span></div></div></div></div><div class=""><div class=""><div class=""><div class=""><span style="font-family: Menlo;" class=""> }</span></div></div></div></div><div class=""><div class=""><div class=""><div class=""><span style="font-family: Menlo;" class="">}</span></div></div></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">Or with the below example:</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class="">struct Point {</font></div></div></div></div></div></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> let x: Int</font></div></div></div></div></div></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> let y: Int</font></div></div></div></div></div></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> let z: Int</font></div></div></div></div></div></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><font face="Menlo" class=""> </font></div></div></div></div></div></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><span style="font-family: Menlo;" class=""> init(self x: Int, self y: Int = 0, self z: Int = 0) {</span><span style="font-family: Menlo;" class="">}</span></div></div></div></div></div></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><span style="font-family: Menlo;" class="">}</span></div></div></div></div></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">Even in all of your futures, I don’t see how you fix the "MxN problem" for let without bringing back the assignment in the type declaration, which was generally not well received.</div><div class=""><br class=""></div><div class=""><br class=""></div><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=""><blockquote type="cite" 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="">Your example hear illustrates the complexity (slightly modified from your proposal’s usage):</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Menlo" class="">struct </font><span style="font-family: Menlo;" class="">Foo {</span></div></div><div class=""><div class=""><span style="font-family: Menlo;" class=""> let</span><span style="font-family: Menlo;" class=""> bar: </span><span style="font-family: Menlo;" class="">String</span></div></div><div class=""><div class=""><span style="font-family: Menlo;" class=""> let</span><span style="font-family: Menlo;" class=""> bas: </span><span style="font-family: Menlo;" class="">Int</span></div></div><div class=""><div class=""><span style="font-family: Menlo;" class=""> let</span><span style="font-family: Menlo;" class=""> baz: </span><span style="font-family: Menlo;" class="">Double</span></div></div><div class=""><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> init(self bar: String, self bas: Int, bax: Int</font><span style="font-family: Menlo;" class="">) {</span></div></div><div class=""><div class=""><span style="font-family: Menlo;" class=""> // self.bar = bar synthesized by the compiler</span></div></div><div class=""><div class=""><div class=""><span style="font-family: Menlo;" class=""> // self.bas = bas synthesized by the compiler</span></div></div></div><div class=""><div class=""><div class=""><span style="font-family: Menlo;" class=""> self</span><span style="font-family: Menlo;" class="">.</span><span style="font-family: Menlo;" class="">baz </span><span style="font-family: Menlo;" class="">=</span><span style="font-family: Menlo;" class=""> </span><span style="font-family: Menlo;" class="">Double</span><span style="font-family: Menlo;" class="">(bax)</span></div></div></div><div class=""><div class=""><font face="Menlo" class=""> }</font></div></div><div class=""><div class=""><font face="Menlo" class="">}</font></div></div></blockquote></div></blockquote><div class=""><br class=""></div><div class="">This approach has been mentioned quite a few times. It results in a lot of duplication without saving a lot. This is especially true if you have a lot of properties and more than one designated initializer that could use memberwise initialization . </div><div class=""><br class=""></div><div class="">IMO, if we were going to take this approach we should at least be able to omit redundant type information and default values for `var` properties where they exist. At least then we are saving as much as we can under this approach.</div><div class=""><br class=""></div><div class="">struct Foo {<br class=""> let bar: String<br class=""> let bas: Int<br class=""> let baz: Double<br class=""><br class=""> init(self bar, self bas, bax: Int) {<br class=""> // self.bar = bar synthesized by the compiler<br class=""> // self.bas = bas synthesized by the compiler<br class=""> self.baz = Double(bax)<br class=""> }<br class="">}</div></div></div></div></blockquote></div><br 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><br class=""></div><div>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><br class=""></div><div>Your critique regarding clarity is very reasonable and it is definitely the biggest drawback with the automatic model. A number of people have commented on both the complexity / lack of clarity as well as the limitations of the automatic model. The opt-in model described in the proposal has some of the same issues. I have started to think more about an opt-in model that would avoid all of those issues. </div><div><br class=""></div><div>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><br class=""></div><div>Matthew</div></div><br class=""></body></html>