<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 6, 2016 at 10:13 AM, Chris Lattner <span dir="ltr">&lt;<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>&gt;</span> wrote:<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"><span style="white-space:pre-wrap">        </span>* What is your evaluation of the proposal?<br></div></blockquote><div><br></div><div><span style="font-size:12.8px">Reluctant -1. This is a well-written and well-considered proposal. However, in the end my opinion is that the improvement it brings to the language is not worth the significant increase in complexity it entails.</span> </div><div><br></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"><span style="white-space:pre-wrap">        </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br></div></blockquote><div><br></div><div>Boilerplate initializers are obnoxious to write but, as other commenters have mentioned, writing them doesn&#39;t actually account for much of how a programmer&#39;s time is spent writing code. The problem this proposal addresses isn&#39;t one of expressiveness or correctness, it&#39;s one of convenience. Features that increase convenience are great, but the benefit-to-complexity they provide is not all that high.</div><div><br></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"><span style="white-space:pre-wrap">        </span>* Does this proposal fit well with the feel and direction of Swift?<br></div></blockquote><div><br></div><div>To be honest, I don&#39;t think so. The core team has articulated their desire for Swift to be a small language that lends itself to building great libraries. Adding significant special-purpose syntactic and semantic complexity to the language in order to cut down on some boilerplate does not really serve that goal. (Add to this the fact that initializers are already complex enough as-is.) A cut-down version of this proposal could satisfy the most common use cases for synthesized initializers, with complex cases deferred to a point where we have a better tool for handling them (like a macro system). </div><div> </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"><span style="white-space:pre-wrap">        </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></div></blockquote><div><br></div><div>n/a</div><div> </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"><span style="white-space:pre-wrap">        </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></div></blockquote><div><br></div><div><span style="font-size:12.8px">I&#39;ve read through both relevant discussion threads with varying levels of attentiveness, as well as the proposal itself.</span><br></div><div><br></div></div></div><div class="gmail_extra">Best,</div><div class="gmail_extra">Austin</div></div>