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

[Jonathan S. Shapiro]

On Wed, Oct 19, 2016 at 6:41 AM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

> If I’m reading the proposal and discussion properly, the group has not
> able to reach consensus on the right criteria for operator symbols, but is
> hopeful that will be possible after the Unicode Consortium completes its
> work.  I think it would be far better to defer the changes to valid
> operator symbols until that time (removing only symbols which are currently
> treated as operators but for which the proposal suggests should be
> available for identifiers instead).
>

Beginning with Swift 4, there will be a major push to ensure that backwards
compatibility with existing code is not broken. It will be possible to
expand the operator character set, but very difficult to shrink it.

Given the current state of the discussion over in Unicode land, I think it
would probably be safe from a compatibility standpoint to admit code points
that fall into the following (Unicode-style) code point set:

[:S:] - [:Sc:] - [:xidcontinue:] - [:nfcqc=n:] & [:scx=Common:] -
pictographics - emoji


into operator characters. In English, this would be:

All symbols excluding currency symbols, provided they are not already in
regular identifiers, requiring that they are legal under NFC normalization
and also that they live in the Common script.

Explicitly exclude pictographics and emojis, not as a value judgment of
UAX31, but because different languages seem to be choosing to go different
ways about whether these are part of normal identifiers or operator
identifiers.

Similar rationale for currency symbols, though I personally believe those
should be operators rather than regular identifiers.


It's possible that other things will go in to UAX31, but it's very hard to
imagine that anything in the set above will end up getting excluded. In
particular, there is some inclination to add some punctuation symbols in
UAX31, but that's going to take some work to ensure that we don't make a
mess inadvertently.

As a transitional matter, I think it would be conservatively safe to add
the code points identified above. Note that it's important to exclude ASCII
code points that are currently "punctuation reserved words". In Swift this
(at least) includes:

. (period, when it does not appear [at least] two times in sequence)
; (Semicolon)
: (Full colon)
$ (Dollar sign - used in special identifiers, which I consider a flaw)
any and all brackets (for now).


IMO, the best argument against using unicode symbols for operators defined
> by mathematics is that they are currently difficult to type.
>

And there is no realistic hope of that changing. This issue is so
compelling that C and C++ introduced standardized text-ascii alternatives
for the punctuation operators to relieve stress on non-english keyboard
users.

This is an argument with a limited lifespan and should not carry more
> weight than it deserves in the design of a language positioned to be the
> language for the next 20 years.  I strongly believe that removing them,
> even temporarily, is a mistake.
>

I think it's good to be a little conservative given the fact that the issue
is more broadly "in flight". That said, I personally believe that the
current proposal has cut back too far.


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