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

[Jonathan S. Shapiro]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161021/8b4fc433/attachment.html>