<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 Feb 16, 2017, at 9:50 PM, Xiaodi Wu 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="">As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised proposal in draft form.<div class=""><br class=""></div><div class="">It proposes a source-breaking change for <b class="">rationalizing</b> which characters are permitted in identifiers and which in operators. It's justified for this phase of Swift 4 because:<div class=""><br class=""></div><div class="">- Existing grammar, in permitting invisible characters without security-minded restrictions, can be <i class="">actively harmful.</i></div><div class="">- A rationalized approach is <i class="">superior</i> to the current approach: by referencing Unicode standards, Swift should be able to evolve in a backwards-compatible way alongside Unicode, and will benefit from the significant expertise of others outside the Swift community with respect to Unicode best practices.</div><div class="">- The vast majority of existing code (including all of the standard library) should <i class="">require no migration</i> work at all</div><div class=""><br class=""></div><div class=""><b class="">What's changed</b> since the last time:</div><div class=""><br class=""></div><div class="">- In an earlier draft, we proposed some radical changes to align with available Unicode standards; in particular, since emoji represent a difficult issue, and no recommendations about "operator identifiers" have surfaced from Unicode, we proposed temporarily stripping them out. This was <i class="">very poorly received</i>. This revision uses Unicode categories to identify nearly all emoji and classify them as identifier characters (while excluding those that depict operators such as !), and it uses Unicode categories to identify over 900 operators that nearly all pass the subjective test of "operator-likeness."</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>I was one of the people leading the charge for preserving Emoji support and I really like where this proposal landed. Thank you to all the authors for the hard work!</div><div><br class=""></div><div><br class=""></div><div>+1</div><div><br class=""></div><div><br class=""></div>Russ</div><br class=""></body></html>