[swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

Russ Bishop xenadu at gmail.com
Tue Feb 21 00:26:45 CST 2017

> On Feb 16, 2017, at 9:50 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised proposal in draft form.
> It proposes a source-breaking change for rationalizing which characters are permitted in identifiers and which in operators. It's justified for this phase of Swift 4 because:
> - Existing grammar, in permitting invisible characters without security-minded restrictions, can be actively harmful.
> - A rationalized approach is superior to the current approach: by referencing Unicode standards, Swift should be able to evolve in a backwards-compatible way alongside Unicode, and will benefit from the significant expertise of others outside the Swift community with respect to Unicode best practices.
> - The vast majority of existing code (including all of the standard library) should require no migration work at all
> What's changed since the last time:
> - In an earlier draft, we proposed some radical changes to align with available Unicode standards; in particular, since emoji represent a difficult issue, and no recommendations about "operator identifiers" have surfaced from Unicode, we proposed temporarily stripping them out. This was very poorly received. This revision uses Unicode categories to identify nearly all emoji and classify them as identifier characters (while excluding those that depict operators such as !), and it uses Unicode categories to identify over 900 operators that nearly all pass the subjective test of "operator-likeness."

I was one of the people leading the charge for preserving Emoji support and I really like where this proposal landed. Thank you to all the authors for the hard work!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/6a7bbb33/attachment.html>

More information about the swift-evolution mailing list