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

[Taylor Swift]

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 at 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 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."
>>
>> 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> 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/20170808/ce4b7642/attachment.html>