Real Swift code uses very very few “unicode” operators, so I would heavily tilt the division towards making most characters identifiers. While I don’t want to talk about specific characters, I often wish I could name variables `∇f` or `∂u∂v`, while no sane API designer would ever use `∇` or `∂` as operators, even though they are considered “mathematical”. I think the bar for making a character an operator should be higher: no character should be classified as an operator if it can appear in language as part of an identifier.
On Tue, Aug 8, 2017 at 2:10 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote: > Is this proposal still on track, or are there other plans to address the > issue of operator and identifier characters in Swift? > > Nevin > > > On Fri, Feb 17, 2017 at 12:50 AM, Xiaodi Wu via swift-evolution < > swift-evolution@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." >> >> What this proposal *does not attempt* to do: >> >> - This document *does not* seek to stake out new ground as to what >> characters should be *added* to the set of valid identifiers and >> operators. Such additions to the grammar are properly separate discussions. >> This proposal is only an attempt at systemization and rationalization. Only >> one character is incidentally added to the list of valid characters (`\`), >> and it is on the basis of an explicit table in Unicode Technical Report 25 >> regarding ASCII characters that are "mathematical." >> >> What feedback would be* most helpful*: >> >> - "Hey, this approach is so much more *clumsy* than my superior, more >> elegant category-based approach to identifying [operators/emoji], which is >> [insert here]." >> - "Hey, I disagree with the detailed design because it's got a *major >> security hole*, which is [insert here]." >> - "Hey, your proposal would break my *real-world* Swift code, which >> requires that character [X] be an [identifier/operator]." >> >> What would be *less helpful*: >> >> - "Hey, let's talk about how [specific character] should be an >> [identifier/operator]. We should add that character to the list of >> [identifiers/operators]. In fact, let's discuss [list] characters one by >> one." >> >> Acknowledgments: >> Thanks to co-authors of the previous take for their support for >> resurrecting this issue. Any brilliant ideas are undoubtedly theirs, and >> any botched efforts are certainly mine. Thanks also to Nevin >> Brackett-Rozinsky for helpful feedback. >> >> Link: >> https://gist.github.com/xwu/d2c2bb7097b0b5a4e9985aae737a2651 >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution