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 > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
