<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 Apr 18, 2016, at 7:39 PM, Douglas Gregor 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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><br class=""><br class="">Sent from my iPhone</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><br class="">On Apr 18, 2016, at 8:56 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><div class=""><br class="">I would like to see Swift Evolution adopt a couple of styles of fast track reviews. Chris Lattner</div><div class="">suggested I bring this up on-list for discussion to allow the community to offer feedback </div><div class="">on my idea.</div><div class=""><br class=""></div><div class=""><b class="">STYLE ONE: Minor language enhancements AKA "Low hanging fruit"</b></div><div class=""><br class=""></div><div class="">I would like the core team to be able to add minor language enhancements without going</div><div class="">through a formal proposal process, with its normal review overhead. I have now been</div><div class="">involved in several reviews that involved API changes that were otherwise unremarkable</div><div class="">and primarily motivated by modernizing and style:</div><div class=""><br class=""></div><div class="">* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0040-attributecolons.md" class="">Replacing Equal Signs with Colons For Attribute Arguments</a></div><div class="">* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md" class="">Modernizing Playground Literals</a></div><div class="">* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md" class="">Disambiguating Line Control Statements from Debugging Identifiers</a></div><div class=""><br class=""></div><div class="">To this list, you could add:</div><div class=""><br class=""></div><div class="">* <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md" class="">Remove explicit use of let from Function Parameters</a></div><div class=""><br class=""></div><div class="">Each of these proposals could have proceeded with a simple "any objections" sanity check </div><div class="">discussion period rather than a more formal full review. As a another example</div><div class="">(<a href="https://github.com/apple/swift-evolution/pull/256" class="">now unnecessary</a>), consider the `dynamicType` keyword, which would have required</div><div class="">a formal proposal to be modernized into Swift's lowercase keyword standard.</div><div class=""><br class=""></div><div class="">The hallmarks of these changes are:</div><div class=""><br class=""></div><div class="">* They have limited impact</div><div class="">* They increase language consistency</div><div class="">* They are uncontroversial, offering simple, straightforward, and correct changes </div><div class=""> that have already passed review in spirit, if not in letter</div><div class="">* A preponderance of reviews are "+1" rather than in-depth discussions of why the proposal </div><div class=""> should or should not be adopted.</div><div class=""><br class=""></div><div class="">I would recommend retaining a change document requirement for these proposals.</div><div class="">This would be similar to a brief but formal proposal, that lays out the justification, </div><div class="">detail design, and any associated background info for the change. Doing so</div><div class="">would provide a historic record of the change and any notes from the team, and be </div><div class="">in a form that would support the extraction of key details for use in release notes.</div><div class=""><br class=""></div><div class="">I do not know whether these would need to be grouped and numbered with the normal</div><div class="">proposals or placed into their own numbering scheme.</div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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="">My main concerns are to have a proper paper trail documenting when and why we make a change. My preferred approach here would be to go through the normal process up to the pull request for the proposal... Then if it's obviously small and good, the core team could just go straight to accept, sending out an announcement. </div></div></blockquote></div><br class=""><div class="">The core team did discuss this, and we agreed that there are small changes (particularly those that come from actually implementing the proposal) that could be treated as “bug fixes” to the proposal. When we accept such a pull request, we will send out an [Amendment] to swift-evolution [*].</div><div class=""><br class=""></div><div class="">We expect to use this sparingly. The removal of the vestigial “let” from function parameter lists is one case where we could have done this, the others are on the fence.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div><div class="">[*] I still owe one of these for a recent pull request we accepted to amend SE-0016.</div><div class=""><br class=""></div></body></html>