Thinking about it further, I am not convinced we need to make *any* change to the set of operator characters at this time. It’s not like people are clamoring to have Braille variable names after all. And as much as I’d like to see the upside-down ampersand (⅋) as an operator, that too can wait.
I am hopeful that this proposal will be revised to focus solely on adopting UAX-31. I am not yet familiar with the specifics of that document, and I expect I am not alone in that regard. Since the proposal indicates several thousand characters will no longer be valid in identifiers, it seems quite possible that some of them may be controversial. I think it is far more productive to spend our collective efforts on making sure we get identifiers right for Swift 4. We can deal with operators in a similar manner once official Unicode guidelines are put forth, so we should not spend time on them now. Nevin On Thu, Oct 20, 2016 at 12:44 AM, Jacob Bandes-Storch via swift-evolution < [email protected]> wrote: > > On Wed, Oct 19, 2016 at 10:12 AM, Alex Martini <[email protected]> wrote: > >> Grammar changes >> >> operator → operator-head operator-characters[opt] >> >> operator-head → ! % & * + - / < = > ? ^ | ~ >> operator-head → operator-dot operator-dots >> operator-character → operator-head >> operator-characters → operator-character operator-character[opt] >> >> operator-dot → . >> operator-dots → operator-dot operator-dots[opt] >> >> >> <https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifier-and-operator-symbology.md#emoji> >> >> >> I think there's a mismatch between the English and grammar. For example, >> is +..+ allowed or not? >> >> The English rule does allow +..+ because its dots appear in a run of two. >> >> The grammar allows a run of one or more dots as an operator head, but >> never allows dots as characters appearing in the middle of an operator, >> regardless of how many dots appear next to each other. The grammar >> wouldn't allow +..+ because the dots don't come at the beginning. >> >> >> >> Here's an alternate version of the grammar that matches the "two or more" >> rule. Because we no longer distinguish between which characters are >> allowed as the first character of an operator vs a character inside, >> there's no longer a need for a separate operator-head. >> >> operator --> operator-character operator-OPT >> >> operator-character --> ! % & * + - / < = > ? ^ | ~ >> operator-character --> operator-dots >> >> operator-dots --> .. operator-additional-dots-OPT >> operator-additional-dots --> . operator-additional-dots-OPT >> > > There is a typo in that operator-character[opt] should be > operator-characters[opt]. Aside from that, though, I believe the grammar as > written accepts +..+ already. Take a look at the following series of > substitutions based on the grammar rules: > > operator > operator-head operator-characters > + operator-characters > + operator-character operator-characters[opt] > + operator-head operator-head > + operator-dot operator-dots operator-head > + . . + > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
