<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 11, 2016, at 1:44 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@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=""><div 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=""><font 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></div></div></div></blockquote><div><br class=""></div><div>No problem. Thanks for responding! </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=""><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 class=""><br class=""></div><div class="">That's what I expected, just wanted to have it spelled out. Thanks.</div><div class=""><br class=""></div><div class=""><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 class=""><br class=""></div><div class="">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></div></div></blockquote><div><br class=""></div><div>Hmm, thought you had agreed with #4 in the discussion about that topic. That said, it is less important in the context of an `internal` or `private` implicit memberwise initializer. </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="">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></div></div></blockquote><div><br class=""></div><div>I can certainly understand your concerns regarding `public` as well as (iii). </div><div><br class=""></div><div>I’m hoping this proposal will be accepted even if some features are removed. Even if only 1-3 or 1-4 were accepted to improve the implicit memberwise initializer I would consider that a good thing. </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="">(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 class=""><br class=""></div><div class="">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></div></div></blockquote><div><br class=""></div><div>I hope you’ll take a look at the new proposals I submitted. I think they provide a better approach to providing this kind of control than the enhancements I included in this proposal. The Partial Initializers proposal might be the best one to look at first. It would effectively supersede the explicit memberwise initializers in this proposal with a more general purpose implementation.</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><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 class=""><br class=""></div><div class="">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></div></div></blockquote></div><div><br class=""></div><div>Glad to hear you think we could omit the type and default value (but still allow for overriding the default value). I think as a sugar feature it needs to save as much as possible to pay its way.</div><div><br class=""></div><div>Another idea along the lines of paying its way as much as possible: maybe if all parameters are “self” parameters you could specify that once at the function level rather than repeating it for every parameter. What do you think about that idea? Maybe something like an @self attribute:</div><div><br class=""></div><div><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">@self public init(x, y) {}</div></div></div></div></div></div></div><div><br class=""></div><div>I agree that it should be obvious where those come from - I think the type and default value would come from the property declaration. Is there anywhere else it could come from?</div><br class=""><div class="">I think this feature could be useful. I just don’t see it as being a complete solution. It would combine with my new Partial Initializers proposal very nicely.</div><div class=""><br class=""></div><div class="">Matthew</div></body></html>