<div dir="ltr">Well, it seems that I jumped the gun and sent my document link to swift-evolution by mistake. Since I can&#39;t take it back, it might be good to say what it&#39;s about. Because of my mistake, this version has <i>not</i> had any review by the rest of the author group, which probably would have improved it a lot. I had intended one more round of edits to deal with a few things that still say &quot;FIX&quot; and a few minor cleanups, but I think the substance of the proposal is sound.<div><br></div><div>This <a href="https://github.com/jsshapiro/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifiers-and-operators.md">revised proposal</a> tries to take into account most of the feedback we have received here. Lots of nitty-gritty changes, but here&#39;s the big picture of the changes:</div><div><ul><li>Emojis are admitted, subject to reasonable sanity conditions.</li><li>A (significantly) broader, but still conservative set of code points are admitted for symbol identifiers. Hopefully this addresses current need, but I remain open to adopting full-on [:Sm:] and [:So:] if there is a strong push for that.</li><li>Operator definition is orthogonal to identifier specification, which deals with the noun/verb confusion and also addresses the widely-expressed feeling that some symbols aren&#39;t operators and their conventional meaning should be usable. The term &quot;operator&quot; no longer has anything to do with identifiers.</li><li>A laundry list of potential parsing gotchas are addressed. The previous proposal would have broken the generics syntax and also the binding syntax. This isn&#39;t a substantive conceptual change, but it&#39;s important if the proposal is going to, you know, <i>actually work</i>. :-)</li><li>Dollar is admitted in identifiers.</li><li>Explicitly addresses anonymous closure parameters in a way that reflects how the compiler actually needs to deal with such things. Might be I&#39;ve written a compiler or two in my career. :-)</li><li>Consistent with the current direction of UAX31 on these issues.</li><li>Susan Kare&#39;s legacy is preserved. :-) If you don&#39;t know who Susan is, look her up and learn why Chris loves the dogcow emoji pair.<br></li></ul>The new proposal remains entirely compatible with Swift 3, except where existing source runs up against the narrower symbol identifier space. It&#39;s a specific goal to avoid breaking reasonable current practice where possible, though we&#39;re surely going to break <i>something</i> with this one.</div><div><br></div><div>I was trained to write specifications in a school that favored rigorous writing. In order to make sure I didn&#39;t lose track of something I rewrote the proposal in a form that I know how to use effectively. Any loss of &quot;fun&quot; in the text is my fault alone.</div><div><br></div><div>Interested to see how this will be received.</div><div><br></div><div><br></div><div>Jonathan</div></div>