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

[Jonathan S. Shapiro]

On Thu, Oct 20, 2016 at 7:30 AM, David Sweeris <davesweeris at mac.com> wrote:

> Sent from my iPhone
>
> On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> Freeze the set of allowed emoji to whatever the current version of the
>> Unicode spec defines...
>>
>
> UAX31 won't include emojis in either space, because there is no clear
> consensus about where they belong (identifiers or operators). Individual
> languages can certainly add them to one space or the other, but should take
> care not to cross-contaminate. So if we add them to operators, we need to
> exclude any that are already part of normal identifiers and vice versa.
> That sanity restriction is technically necessary, but it shouldn't be an
> inconvenience in practical terms.
>
>
> My understanding (which is admittedly fuzzy) is that the distinction
> between operators and identifiers is only "technically necessary" because
> allowing characters to be both causes the parsing algorithm lose its
> virtual mind, and it takes a century for it to figure out what's going on.
> What I don't recall being discussed before is whether that's a blanket
> penalty or if the compile times increases are proportional to the amount
> overlap between the two character sets.
>

The hard requirements are:

   1. Nothing in identifier start can be in operator start or operator
   continue. [*]
   2. Nothing in operator start can be in identifier start or identifier
   continue. [*]
   3. Nothing in syntactic punctuation (period, brackets, parens, and so
   forth) can be in either type of identifier without creating a lot of
   serious hair. You can see one example of hair in the "double dots" rule.

If these requirements are not preserved, the consequence is that white
space becomes required between identifiers and operators. So, for example,
without these rules:

a+b    // gets broken

a + b  // works


The presence of dots in operators is actually causing a whole bunch of
constraints to get introduced that I'm going to talk about in a moment.


Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161020/ebee9b79/attachment.html>