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

[Matthew Johnson]

> On Oct 19, 2016, at 12:29 PM, Jonathan S. Shapiro <jonathan.s.shapiro at gmail.com> wrote:
> 
> On Wed, Oct 19, 2016 at 6:41 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto: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:
> 

Am I reading this correctly that you are suggesting we expand the proposal to include this set of operator characters?  If this is what you are suggesting I would drop my opposition to the proposal as it would no longer take away a bunch of very common mathematical operators.  I believe defining the included set this way would also address Xiaodi’s concerns about including the set operators.

> [: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/869f4c22/attachment.html>