[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Daniel Duan]

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.

> On Oct 21, 2016, at 9:38 PM, Jonathan S. Shapiro via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 not 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.
> 
> This revised proposal <https://github.com/jsshapiro/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifiers-and-operators.md> 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:
> Emojis are admitted, subject to reasonable sanity conditions.
> 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.
> 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.
> 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, actually work. :-)
> Dollar is admitted in identifiers.
> 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. :-)
> Consistent with the current direction of UAX31 on these issues.
> 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.
> 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 something with this one.
> 
> 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.
> 
> Interested to see how this will be received.
> 
> 
> Jonathan
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161022/621895f7/attachment.html>