<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 19, 2016, at 12:29 PM, Jonathan S. Shapiro <<a href="mailto:jonathan.s.shapiro@gmail.com" class="">jonathan.s.shapiro@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><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" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">[:S:] - [:Sc:] - [:xidcontinue:] - [:nfcqc=n:] & [:scx=Common:] - pictographics - emoji</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">into operator characters. In English, this would be:</div><div class=""><br class=""></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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 class=""><br class=""></div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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 class=""><br class=""></div><div class="">Similar rationale for currency symbols, though I personally believe those should be operators rather than regular identifiers.</div></div></div></blockquote><div class=""><br class=""></div>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.<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="">. (period, when it does not appear [at least] two times in sequence)</div><div class="">; (Semicolon)</div><div class="">: (Full colon)</div><div class="">$ (Dollar sign - used in special identifiers, which I consider a flaw)</div><div class="">any and all brackets (for now).</div></blockquote><div class=""><br class=""></div><div class=""><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" class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></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" class=""><div class="">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 class=""><br class=""></div><div class="">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. </div></div><br class=""></div></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Jonathan</div></div>
</div></blockquote></div><br class=""></body></html>