<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Mar 17, 2016, at 10:45 PM, Nicholas Maccharoli via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><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 class=""></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" class="">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 class=""></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 class=""></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" class=""></div></div></blockquote></div><br class=""><div class="">Because the proposals act as documentation for the evolution process, I think it may be worth </div><div class="">expanding the motivation section and the impact on existing code slightly.</div><div class=""><br class=""></div><div class=""><div class="">You mention <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0003-remove-var-parameters.md" class="">SE-0003</a> which removed var parameters and state "it would make sense </div><div class="">that the syntax for function parameters being explicitly declared as `let` would be removed as well."</div></div><div class=""><br class=""></div><div class="">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" class="">SE-0001</a> restricted `inout`, `var`, and `let` as argument labels. </div><div class="">SE-0003 removed `var, and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0031-adjusting-inout-declarations.md" class="">SE-0031</a> moved `inout` declarations to the type, leaving `let` </div><div class="">as the last remaining exception to SE-0001. Removing it reverts SE-0001 to a clear implementation </div><div class="">without special cases.</div><div class=""><br class=""></div><div class="">You might also mention `let` in its current use is redundant since its inclusion does not and </div><div class="">cannot modify the behavior of the declaration it decorates. It is rarely if ever used and in the </div><div class="">circumstances when added produces no positive contribution to the language since the behavior </div><div class="">is identical to its absence. </div><div class=""><br class=""></div><div class="">In the Impact on Existing Code section, you suggest "The `let` keword would have to be deleted if </div><div class="">placed before a function parameter." I'd recommend mentioning the migrator specifically and</div><div class="">adding that if not migrated, the let will be be now be interpreted as an external label.</div><div class=""><br class=""></div><div class="">-- E, who probably thought about this one a little too hard</div><div class=""><br class=""></div></body></html>