<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
The review of "Flexible Memberwise Initialization" begins now and runs through January 10th. The proposal is available here:<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md</a><br></blockquote><div><br></div><div> <snip></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * What is your evaluation of the proposal?<br></blockquote><div> A slightly hesitant +1. I think there may be a more general approach that would have benefits across the language, although that approach would still need several specific accommodations to work for init. I’m not sure a comparable solution would land anywhere better in the complexity space, though it could probably provide a less narrow set of advantages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Is the problem being addressed significant enough to warrant a change to Swift?<br></blockquote><div> Yes. Initialization is fundamental to Swift, and as it stands right now there is too much boilerplate. I believe this proposal carefully worked through the space of attempting to minimize need for boilerplate in enough common cases without requiring too much special knowledge. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Does this proposal fit well with the feel and direction of Swift?<br></blockquote><div>I think so, overall. It strikes a pretty good balance. I am reluctant to make teaching initialization any more difficult, but I looked through the proposal yet again with an eye towards how I would teach this new feature along with everything else and I believe it is manageable (and in fact not as high a cost as I assumed previously). I don’t think most of the future possible directions will be needed or beneficial, but the proposal as it stands today does not complicate the language overly much from my perspective, relative to its benefits. I do wish some of the ideas on a more general solution had come up earlier and had time to be more fully explored. Using a broader feature with specialization for init would be the best possible improvement in fitting with Swift that I could imagine. </div><div><br></div><div>In the end I think this is a good and very well thought through proposal on memberwise initialization. I think it strikes a very good balance on capability vs additional complexity, with the caveat that I think it is a bit too narrow and we should have explored a more general variadic args capability to underly this feature earlier. However I’m not sure we should hold up this proposal based on that hypothetical, especially since much of the initialization-specific capabilities would still need to be addressed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></blockquote><div>Nothing comes to mind that would be comparable. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></blockquote><div>I’ve followed the entire discussion(s) on Swift-Evolution, and read the proposal several times. I went through some of our Swift codebase, and thought through the impact on our Initialization lecture and materials.</div><div><br></div><div>- Step</div><div><br></div></div></div></div>