<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 Sep 18, 2016, at 6:24 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="">On Sun, Sep 18, 2016 at 9:19 PM, Erica Sadun via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><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" class=""><div class="">Let me tl;dr'er this even more: βΉοΈ is an operator, but π is an identifier.</div><div class=""><br class=""></div><div class="">-- E, succinct, who thinks there's room for improvement</div></div></blockquote><div class=""><br class=""></div><div class="">Ha, yes. Let's see if I can be as succinct in my contribution to the discussion:</div><div class=""><br class=""></div><div class="">1) Agree that current situation not ideal, for reasons above</div></div></div></div></div></blockquote><div><br class=""></div>+1, totally agreed. We really need to improve this, aiming for Swift 3.1 or Swift 4 seems like a really good idea, because the appetite for this sort of change will probably be very low after Swift 4.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">2) The solution might best be not one but several proposals:</div><div class=""><br class=""></div><div class=""> 2a) Unicode normalization: invisible characters, Greek tonos, etc. (cf. previous message about previously proposed solution, which reflects Unicode recommendations in UTR #31)--low hanging fruit: there's an established Unicode recommendation with clear wins for security and consistency</div><div class=""><br class=""></div><div class=""><div class=""> 2b) Legal and illegal characters for identifiers *or* operators: UTR #31 makes recommendations regarding rarely used scripts; probably best to follow the letter and spirit of these recommendations (which would probably mean ancient Greek musical symbols and Egyptian hieroglyphics shouldn't be identifier or operator characters)</div></div><div class=""><br class=""></div><div class=""> 2c) Decisions as to which characters are identifier characters or operator characters: for instance, emoji should probably never be operator characters; if an emoji has a non-emoji counterpart that is an operator (βοΈβββββοΈ, etc.) it might be best simply to make these illegal rather than operator characters</div><div class=""><br class=""></div><div class=""> 2d) Confusables: I think the last time we had this discussion, it was apparent that it'd be difficult to decide which confusables to allow or disallow after some of the low-hanging fruit is taken care of by Unicode normalization (see item 2a); the Unicode Consortium-provided list seems too quick to call two things "confusable" for our purposes (with criteria that might be relevant for URLs or other use cases, but casting too wide a net perhaps for Swift identifiers)</div></div></div></div></div></blockquote><br class=""></div><div>These all seem like good points. I agree that we should default to following an existing Unicode standard unless there is a really good reason to deviate.</div><div><br class=""></div><div><div>I donβt have an opinion about the specific direction of the proposal though.</div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"></div></div></div></blockquote></div></div><div>-Chris</div><br class=""></body></html>