[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Nevin Brackett-Rozinsky]

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 <
swift-evolution at swift.org> wrote:

>
> On Wed, Oct 19, 2016 at 10:12 AM, Alex Martini <amartini at apple.com> 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
> 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/20161020/7a4f5b05/attachment.html>