<div dir="ltr">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.<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 2:10 PM, Nevin Brackett-Rozinsky via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is this proposal still on track, or are there other plans to address the issue of operator and identifier characters in Swift?<div><br></div><div>Nevin</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 17, 2017 at 12:50 AM, Xiaodi Wu via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised proposal in draft form.<div><br></div><div>It proposes a source-breaking change for <b>rationalizing</b> which characters are permitted in identifiers and which in operators. It's justified for this phase of Swift 4 because:<div><br></div><div>- Existing grammar, in permitting invisible characters without security-minded restrictions, can be <i>actively harmful.</i></div><div>- A rationalized approach is <i>superior</i> 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.</div><div>- The vast majority of existing code (including all of the standard library) should <i>require no migration</i> work at all</div><div><br></div><div><b>What's changed</b> since the last time:</div><div><br></div><div>- 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 <i>very poorly received</i>. 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."</div><div><br></div><div>What this proposal <b>does not attempt</b> to do:</div><div><br></div><div>- This document <i>does not</i> seek to stake out new ground as to what characters should be <i>added</i> 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."</div></div><div><br></div><div>What feedback would be<b> most helpful</b>:</div><div><br></div><div>- "Hey, this approach is so much more <b>clumsy</b> than my superior, more elegant category-based approach to identifying [operators/emoji], which is [insert here]."<br></div><div>- "Hey, I disagree with the detailed design because it's got a <b>major security hole</b>, which is [insert here]."</div><div>- "Hey, your proposal would break my <b>real-world</b> Swift code, which requires that character [X] be an [identifier/operator]."</div><div><br></div><div>What would be <b><i>less</i> helpful</b>:</div><div><br></div><div>- "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."</div><div><br></div><div>Acknowledgments:</div><div>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.</div><div><br></div><div>Link:</div><div><a href="https://gist.github.com/xwu/d2c2bb7097b0b5a4e9985aae737a2651" target="_blank">https://gist.github.com/xwu/d2<wbr>c2bb7097b0b5a4e9985aae737a2651</a><br></div><div><br></div></div>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>