<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 19, 2016 at 6:41 AM, Matthew Johnson via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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).</div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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:</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>[:S:] - [:Sc:] - [:xidcontinue:] - [:nfcqc=n:] &amp; [:scx=Common:] - pictographics - emoji</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>into operator characters. In English, this would be:</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div><div>Similar rationale for currency symbols, though I personally believe those should be operators rather than regular identifiers.</div></div></div></blockquote><div><br></div>It&#39;s possible that other things will go in to UAX31, but it&#39;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&#39;s going to take some work to ensure that we don&#39;t make a mess inadvertently.<div><br></div><div>As a transitional matter, I think it would be conservatively safe to add the code points identified above. Note that it&#39;s important to exclude ASCII code points that are currently &quot;punctuation reserved words&quot;. In Swift this (at least) includes:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>. (period, when it does not appear [at least] two times in sequence)</div><div>; (Semicolon)</div><div>: (Full colon)</div><div>$ (Dollar sign - used in special identifiers, which I consider a flaw)</div><div>any and all brackets (for now).</div></blockquote><div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>IMO, the best argument against using unicode symbols for operators defined by mathematics is that they are currently difficult to type.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div></div></blockquote><div><br></div><div>I think it&#39;s good to be a little conservative given the fact that the issue is more broadly &quot;in flight&quot;. That said, I personally believe that the current proposal has cut back too far. </div></div><br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Jonathan</div></div>