<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 Oct 18, 2016, at 11:34 PM, Jacob Bandes-Storch 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="">Dear Swift-Evolution community,</div><div class=""><br class=""></div><div class="">A few of us have been preparing a proposal to refine the definitions of identifiers & operators. This includes some changes to the permitted Unicode characters.</div><div class=""><br class=""></div><div class="">The latest (perhaps final?) draft is available here:</div><div class=""><br class=""></div><div class=""> <a href="https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifier-and-operator-symbology.md" class="">https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifier-and-operator-symbology.md</a></div><div class=""><br class=""></div><div class="">We'd welcome your initial thoughts, and will probably submit a PR soon to the swift-evolution repo for a formal review. Full text follows below.</div></div></div></blockquote><div><br class=""></div><div>I haven’t had a chance to read the entire proposal, nor the tons of great discussion down thread, but here are a few thoughts, just MHO:</div><div><br class=""></div><div>- I’m loving that you’re taking a detail oriented approach to the problem. I agree with you that our current approach is unprincipled, and we need to get this right for Swift 4.</div><div>- I think that it is perfectly fine to err on the side of conservatism: if it isn’t clear how to classify something (e.g. Braille patterns), we should just reject them in both operators and identifiers (make them be unassigned). If these unclear cases are important to someone, then we can consider (as a separate additive proposal) adding them back later.</div><div>- As to conservatism, explicitly reserving “..” (for possible future language directions) seems reasonable to me. Are there any other similar things we should consider reserving?</div><div><br class=""></div><div>- I applaud the creativity keeping 🐶🐮 a valid identifier :-), but it is really missing the point. *All* of the non-symbol-like emoji’s should be valid in identifiers. With a quick unscientific look at Apple’s character picker, all the emojis other than a few in “Symbols” seem like they should be identifiers. It would be fine to conservatively leave all emoji “symbols” as unassigned.</div><div>- I really think we should keep symbols as operators, including much of the math symbols (e.g. ∪). In a later separate proposal, we can consider whether it makes sense for emoji symbols (like ✖️to be usable as operators), I can see arguments both ways.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></div></body></html>