<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="">It’s worth pointing out that the proposal to add ‘$’ to identifiers is still under active review and have generated much controversy. I wouldn’t put much weight in “backward compatibility” for that proposal.<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Oct 21, 2016, at 9:38 PM, Jonathan S. Shapiro 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="">Well, it seems that I jumped the gun and sent my document link to swift-evolution by mistake. Since I can't take it back, it might be good to say what it's about. Because of my mistake, this version has <i class="">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 "FIX" and a few minor cleanups, but I think the substance of the proposal is sound.<div class=""><br class=""></div><div class="">This <a href="https://github.com/jsshapiro/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifiers-and-operators.md" class="">revised proposal</a> tries to take into account most of the feedback we have received here. Lots of nitty-gritty changes, but here's the big picture of the changes:</div><div class=""><ul class=""><li class="">Emojis are admitted, subject to reasonable sanity conditions.</li><li class="">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 class="">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't operators and their conventional meaning should be usable. The term "operator" no longer has anything to do with identifiers.</li><li class="">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't a substantive conceptual change, but it's important if the proposal is going to, you know, <i class="">actually work</i>. :-)</li><li class="">Dollar is admitted in identifiers.</li><li class="">Explicitly addresses anonymous closure parameters in a way that reflects how the compiler actually needs to deal with such things. Might be I've written a compiler or two in my career. :-)</li><li class="">Consistent with the current direction of UAX31 on these issues.</li><li class="">Susan Kare's legacy is preserved. :-) If you don't know who Susan is, look her up and learn why Chris loves the dogcow emoji pair.<br class=""></li></ul>The new proposal remains entirely compatible with Swift 3, except where existing source runs up against the narrower symbol identifier space. It's a specific goal to avoid breaking reasonable current practice where possible, though we're surely going to break <i class="">something</i> with this one.</div><div class=""><br class=""></div><div class="">I was trained to write specifications in a school that favored rigorous writing. In order to make sure I didn't lose track of something I rewrote the proposal in a form that I know how to use effectively. Any loss of "fun" in the text is my fault alone.</div><div class=""><br class=""></div><div class="">Interested to see how this will be received.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jonathan</div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>