> On Oct 19, 2016, at 12:29 PM, Jonathan S. Shapiro > <[email protected]> wrote: > > On Wed, Oct 19, 2016 at 6:41 AM, Matthew Johnson via swift-evolution > <[email protected] <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
