<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 9:43 AM, Tal Atlas <<a href="mailto:me@tal.by" class="">me@tal.by</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" 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="">Overall I think this is a definite improvement to the current status quo and something needs to be solved. My only concern with this specific proposal is that on an initial glance it's not easy to intuit what the behavior is. I like the end result of this proposal, and I think since it'd be frequently used it'd be easy to remember what it was despite being unintuitive.<div class=""><br class=""></div><div class="">I had originally suggested this alternative:</div><div class="">```</div><div class=""><div class="">struct Foo {</div><div class=""> let bar: String</div><div class=""> let bas: Int</div><div class=""> let baz: Double</div><div class=""> init(self.bar: String, self.bas: Int, bax: Int) {</div><div class=""> // self.bar = bar synthesized by the compiler</div><div class=""> // self.bas = bas synthesized by the compiler</div><div class=""> self.baz = Double(bax)</div><div class=""> }</div><div class="">}</div></div><div class="">```</div><div class="">The upside of this is that it's more clear what happens, downside is that adding a property requires 2 changes (as opposed to current 3, but more than the 1 change required in proposal).</div></div></div></blockquote><div><br class=""></div><div>The problem with this is that you have to duplicate information and you may often have more than one initializer. It ends up being much more verbose. I don’t think it adds enough value over fully manual initialization to warrant a language change.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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=""><div class=""><br class=""></div><div class="">Perhaps a syntax more along the lines of this would be more intuitive and still eliminate the boilerplate.</div><div class="">```</div><div class=""><div class="">struct Foo {</div><div class=""> let bar: String</div><div class=""> let bas: Int</div><div class=""> let baz: Double</div><div class=""> init(bax: Int, self = ...) {</div><div class=""> // self.bar = bar synthesized by the compiler</div><div class=""> // self.bas = bas synthesized by the compiler</div><div class=""> self.baz = Double(bax)</div><div class=""> }</div><div class="">}</div></div><div class="">```</div><div class="">`memberwise` means nothing to the uninitiated, and `...` without any other operator is a little confusing. I think this solves the issue of saying what the `...` is doing.</div></div></div></blockquote><div><br class=""></div><div>I don’t like this. People are going to have to learn the language regardless of the syntax. Remember that the initializer will have the `memberwise` declaration modifier in addition to the `…` in the parameter list. I don’t think `self = …` would be more clear than that to people who have learned about memberwise initialization. And it feels like something that should belong in the body of the initializer if it was required.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><br 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=""><div class="gmail_quote" 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;"><div dir="ltr" class="">On Thu, Jan 7, 2016 at 10:12 AM Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 2:46 AM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div class=""><blockquote type="cite" class=""><span style="white-space: pre-wrap;" class=""> </span>* What is your evaluation of the proposal?<br class=""></blockquote><br class="">+1 to the basic proposal. I'm much more reserved about the "Future enhancements"; some I don't want at all, some sound plausible but probably need changes.<br class=""></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">Thanks for your support Kevin! </div><div class=""><br class=""></div><div class="">As I stated last night, there are two primary things that I think need improving via enhancements of some kind. I hope you can agree with these points:</div><div class=""><br class=""></div><div class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="">1. We need a way to specify a default value for memberwise parameters for `let` properties.</div></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="">2. We need a little bit more control over which properties participate in memberwise initialization when the “automatic” rules don’t quite do the right thing for a particular use case.</div><div class=""><br class=""></div><div class="">Most of the enhancements listed show various ways we could address the second point. We don’t need all of them. </div><div class=""><br class=""></div><div class="">Under the current proposal there will be cases where memberwise initialization would be of great use, but the rules of the automatic model expose a property (probably a `let`) that shouldn’t be exposed. We won’t be able to use memberwise initialization at all in those cases if we don’t have a way to correct that behavior.</div><div class=""><br class=""></div><div class="">There may also be cases where a property doesn’t participate in memberwsie initialization when we would like it to. In those cases we can add an explicit parameter and manually initialize the property, continuing to use memberwise initialization for other properties.</div><div class=""><br class=""></div><div class="">Ideally we can find a simple enhancement that solves both visibility problems. I’m definitely open to any ideas on how we can handle this.</div></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Also, a question and a concern about the basic proposal. The question: you state that the only impact this has on existing code is structs with private properties that have been getting an implicit internal memberwise initializer will have the initializer be private. That's fine, but assuming that the implicit memberwise initializer behaves identically to `memberwise init(...) {}`, surely this proposal also makes the implicit memberwise initializer gain defaulted arguments for any var properties with an initializer expression? Don't get me wrong, I think it's good to change that, but it should be explicitly noted.<br class=""></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">That is a great point! It won’t break any existing code, but it will change behavior slightly. I will update the proposal and submit a PR with this change.</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">As for my concern, it's with the following rule:<br class=""><br class=""><blockquote type="cite" class="">If the initializer body assigns to a var property that received memberwise initialization synthesis report a warning. It is unlikely that overwriting the value provided by the caller is the desired behavior.<br class=""></blockquote><br class="">I understand why you put this in there, but this is a warning that cannot be suppressed and will make it impossible to use a memberwise initializer for perfectly legitimate cases where you do in fact want to mutate the property after it's been assigned to.<br class=""></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">For normal initializers I agree with you. However, I think it’s a reasonable for callers to assume that if you expose a property via memberwise initialization the post-initialization value will match the value they provide. This warning is intended to alert you to the fact that you are violating that reasonable assumption.</div><div class=""><br class=""></div><div class="">Do you have an example of where you would want a caller to initialize a property, but then overwrite the value they provide<span class="Apple-converted-space"> </span><b class="">during initialization</b>?</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">What might be a reasonable thing is a warning that occurs if you assign to the var property without ever having read from it (i.e. a dead store warning on the memberwise initialization of the property). That way if I mutate a property to contain a derived value it's fine, but if I simply write to it without ever reading it, it's a problem.</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><span style="white-space: pre-wrap;" class=""> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></blockquote><br class="">I think so. Writing initializers can be a large source of boilerplate in Swift, especially when using classes where you can't get the implicit memberwise initializer.<br class=""><br class=""><blockquote type="cite" class=""><span style="white-space: pre-wrap;" class=""> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></blockquote><br class="">Yes.<br class=""><br class=""><blockquote type="cite" class=""><span style="white-space: pre-wrap;" class=""> </span>* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></blockquote><br class="">I'm not aware of a similar feature in any language I'm familiar with.<br class=""><br class=""><blockquote type="cite" class=""><span style="white-space: pre-wrap;" class=""> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></blockquote><br class="">I spent a few minutes reading over the whole proposal. I did not read any of the swift-evolution thread.<br class=""><br class="">-Kevin Ballard<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div></div><div style="word-wrap: break-word;" class=""><div class=""></div><br class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RVJ3oK8DhV2nk8GArr3gdPix5kxIdH2eteeGb4fQAElgi4B1fqRMIRCn67zieEoZ1ufAr2URxXF8LGi3VDNv3-2FdxB-2FtQJRAT-2BXAgZwK06WpZGLyv4er-2FPzk1lEH2qdMaaXoiMKMJdO2TRWpKYg3V4NzgJ7alCxS00E-2Bme2lf5SccnZOS27H93cQVgusj0fyP0HRNJA7eREmsyarYn9TCjg-3D-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></blockquote></div><br class=""></body></html>