<div dir="ltr"><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">Thanks for the pointers Erica! </div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">I have updated the motivation section and the section on the impact on existing code.</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">How does the proposal look now?</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">- Nick</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><br><div>All the best,</div><div><br></div><div>Nicholas</div><div><br></div><div>Linked in:</div><div><font size="2"><a href="http://lnkd.in/328U22" target="_blank">http://lnkd.in/328U22</a></font><br></div><div><br></div></div></div></div>
<br><div class="gmail_quote">On Fri, Mar 18, 2016 at 11:33 PM, Erica Sadun <span dir="ltr"><<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Mar 17, 2016, at 10:45 PM, Nicholas Maccharoli via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-family:'comic sans ms',sans-serif;color:rgb(39,78,19)">Thank you!</div><div class="gmail_default" style="font-family:'comic sans ms',sans-serif;color:rgb(39,78,19)"><br></div><div class="gmail_default" style="font-family:'comic sans ms',sans-serif;color:rgb(39,78,19)">I have filed a PR here: <a href="https://github.com/apple/swift-evolution/pull/215" target="_blank">https://github.com/apple/swift-evolution/pull/215</a></div><div class="gmail_default" style="font-family:'comic sans ms',sans-serif;color:rgb(39,78,19)"><br></div><div class="gmail_default" style="font-family:'comic sans ms',sans-serif;color:rgb(39,78,19)">How does it look?</div><div class="gmail_default" style="font-family:'comic sans ms',sans-serif;color:rgb(39,78,19)"><br></div><div class="gmail_default" style="font-family:'comic sans ms',sans-serif;color:rgb(39,78,19)">- Nick</div></div><div class="gmail_extra"><br clear="all"></div></div></blockquote></div><br></span><div>Because the proposals act as documentation for the evolution process, I think it may be worth </div><div>expanding the motivation section and the impact on existing code slightly.</div><div><br></div><div><div>You mention <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0003-remove-var-parameters.md" target="_blank">SE-0003</a> which removed var parameters and state "it would make sense </div><div>that the syntax for function parameters being explicitly declared as `let` would be removed as well."</div></div><div><br></div><div>I think it may be worth adding that <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0001-keywords-as-argument-labels.md" target="_blank">SE-0001</a> restricted `inout`, `var`, and `let` as argument labels. </div><div>SE-0003 removed `var, and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0031-adjusting-inout-declarations.md" target="_blank">SE-0031</a> moved `inout` declarations to the type, leaving `let` </div><div>as the last remaining exception to SE-0001. Removing it reverts SE-0001 to a clear implementation </div><div>without special cases.</div><div><br></div><div>You might also mention `let` in its current use is redundant since its inclusion does not and </div><div>cannot modify the behavior of the declaration it decorates. It is rarely if ever used and in the </div><div>circumstances when added produces no positive contribution to the language since the behavior </div><div>is identical to its absence. </div><div><br></div><div>In the Impact on Existing Code section, you suggest "The `let` keword would have to be deleted if </div><div>placed before a function parameter." I'd recommend mentioning the migrator specifically and</div><div>adding that if not migrated, the let will be be now be interpreted as an external label.</div><div><br></div><div>-- E, who probably thought about this one a little too hard</div><div><br></div></div></blockquote></div><br></div>