<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><div class=""><div 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=""><font color="#000000" class="">Sorry to leave this over the weekend before getting back to you! Planning to respond here, then go catch up on the thread—a possibly questionable ordering of tasks, but one that ensures I will actually respond at all.</font><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div 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=""><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=""><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<span class="Apple-converted-space"> </span><i class="">both</i> in the same type?</div></div></div></blockquote><div class=""><br class=""></div><div class="">If you have at least one internal property they would result in different signatures so would not be a duplicate declaration. The public memberwise init would obviously need to initialize the internal property somehow.</div></div></div></blockquote><div><br class=""></div><div>That's what I expected, just wanted to have it spelled out. Thanks.</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div 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=""><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=""> 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></div></blockquote><div class=""><br class=""></div><div class="">I can certainly sympathize with this. It is the big drawback of the automatic model. At the same time, this proposal builds on the existing memberwise init for structs and doesn’t really make the rules that much more complex. But it does make the feature more prevalent and visible, thus making it more important to understand the rules. And of course it could be argued that the current memberwise init is too complex as it is.</div><div class=""><br class=""></div><div class="">For the record, here is a concise list of how this proposal expands the current memberwise init:</div><div class=""><br class=""></div><div class=""><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=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>i. Add additional parameters</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>ii. include an initializer body</div></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>iii. Specify access level, which will result in omission of memberwise parameters for more-private properties (it would be reasonable to limit this to private and internal if concerns about allowing it to be public are a significant factor)</div></div><div class=""><br class=""></div><div class="">I am curious to hear your thoughts on which of these points are not desirable, and what your opinion is about the existing rules for the implicit memberwise init for structs.</div></div></div></blockquote><div><br class=""></div><div>I'm happy with 1, 2, and 3 as a separate proposal, or several separate proposals. (For 1 in particular, the restriction predates the access control model, but making it implicit would also interfere with inheriting designated initializers.) I'm not sure 4 is interesting enough, but sure.</div><div><br class=""></div><div>The particular concern I have with 5 is that the <i class="">most</i> interesting use case to me is for 'public' (indeed, that's by far the majority of the requests for this we've seen in Radar, <a href="rdar://problem/18065955" class="">rdar://problem/18065955</a>), but that's also the most dangerous one if you have <i class="">anything</i> unusual going on: different access control, library evolution, etc. (i) and (ii) are mostly just extra features, but (iii) is where it gets weird.</div><div><br class=""></div><div>(The next most common request related to this proposal is 1, memberwise inits for classes, mostly in simple cases. <a href="rdar://problem/16704095" class="">rdar://problem/16704095</a>)</div><div><br class=""></div><div>For public memberwise inits, I think my discomfort ultimately comes down to "the order of stored properties in a class is not usually part of the class's ABI", and this makes it too easy to opt into that, and then too hard to explain <i class="">which</i> members and why. There's also the problem of wanting to tweak <i class="">one</i> parameter's behavior, and being unable to do that; having to build <i class="">more</i> features on top of this one to fix that seems like it's going in the wrong direction.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div 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=""><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=""><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 class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">public struct Point {</div></blockquote><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"> public var x: Double</blockquote><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"> public var y: Double</blockquote><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"> public init(self x: Double, self y: Double) {}</blockquote><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;">}</blockquote><div class=""><br class=""></div><div class="">or</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""> public init(@assigned x: Double, @assigned y: Double) {}</div></blockquote><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"> public init(self.x: Double, self.y: Double) {}<br class=""> // something else</blockquote><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I’ll ask you the same question I asked David about this approach: if the parameter must be explicitly related to a property for assignment, why should we repeat the type information (and default value information if it is a var)? Doesn’t it seem reasonable to omit the type?</div></div></div></blockquote><div><br class=""></div><div>I'm happy to come up with a syntax to omit the type and default value; I do still think the listing of parameters should be explicit. (And it should be obvious where it gets any type and default value <i class="">from.</i>)</div><div><br class=""></div><div>Jordan</div></div></body></html>