<div dir="ltr">On Sat, Oct 22, 2016 at 1:37 AM, Nevin Brackett-Rozinsky via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><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 dir="ltr">I just read through your new proposal, and I have to say it is extremely well-written. There is a vast quantity of information presented quite clearly, and it gives me a lot to think about.<div><br></div><div><br></div><div><div class="gmail_quote">On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro <span dir="ltr"><<a href="mailto:jonathan.s.shapiro@gmail.com" target="_blank">jonathan.s.shapiro@<wbr>gmail.com</a>></span> wrote:<span class=""><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_7575801398747489515gmail-">On Fri, Oct 21, 2016 at 1:54 PM, Nevin Brackett-Rozinsky via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-<wbr>evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I think it is plainly evident that the well-defined criteria you would like to use *have not yet been defined* by Unicode. That is a large part of why I recommend that we postpone a major overhaul of our operator characters.</div></blockquote><div><br></div></span><div>That's a feasible way to go, but keep in mind that the UAX31 changes are being co-designed with and informed by the current discussion. There are a bunch of things that have come up here that will allow UAX31 to side-step some "might have happened" mistakes, so this discussion has been very useful.</div><div><br></div><div>The Swift community can and should make its own decision about whether to remain engaged. The risk of disengagement is that messy compatibility issues will probably have to be faced later that we can easily head-off now.</div></div></div></div></blockquote><div><br></div></span><div>Ah, I had not previously understood that. Well then, in light of the fact that the Unicode recommendations may be influenced by our decisions, and given that Swift is an opinionated language, it follows that we ought to make our best effort at separating out what we have been calling “operator characters” (and your revised proposal calls “symbol identifier” characters).</div><div><br></div><div>In particular, since there does not yet exist a categorization of symbols which fits our needs, and since our needs may help shape such a categorization as it forms, it behooves us to fully undertake the endeavor of defining which symbols we would like to see in which roles for Swift.</div><div><br></div><div>Your proposal mentions and links to a set of <a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%21%5C%24%25%5C%26*%2B%5C-%2F%3C%3D%3E%3F%5C%5E%7C%7E%0D%0A%0D%0A%5Cu00AC%0D%0A%5Cu00B1%0D%0A%5Cu00B7%0D%0A%5Cu00D7%0D%0A%5Cu00F7%0D%0A%0D%0A%5Cu2208-%5Cu220D%0D%0A%5Cu220F-%5Cu2211%0D%0A%5Cu22C0-%5Cu22C3%0D%0A%5Cu2212-%5Cu221D%0D%0A%5Cu2238%0D%0A%5Cu223A%0D%0A%5Cu2240%0D%0A%5Cu228C-%5Cu228E%0D%0A%5Cu2293-%5Cu22A3%0D%0A%5Cu22BA-%5Cu22BD%0D%0A%5Cu22C4-%5Cu22C7%0D%0A%5Cu22C9-%5Cu22CC%0D%0A%5Cu22D2-%5Cu22D3%0D%0A%5Cu2223-%5Cu222A%0D%0A%5Cu2236-%5Cu2237%0D%0A%5Cu2239%0D%0A%5Cu223B-%5Cu223E%0D%0A%5Cu2241-%5Cu228B%0D%0A%5Cu228F-%5Cu2292%0D%0A%5Cu22A6-%5Cu22B9%0D%0A%5Cu22C8%0D%0A%5Cu22CD%0D%0A%5Cu22D0-%5Cu22D1%0D%0A%5Cu22D4-%5Cu22FF%0D%0A%5Cu22CE-%5Cu22CF%0D%0A%0D%0A%5Cu2A00-%5Cu2AFF%0D%0A%0D%0A%5Cu27C2%0D%0A%5Cu27C3%0D%0A%5Cu27C4%0D%0A%5Cu27C7%0D%0A%5Cu27C8%0D%0A%5Cu27C9%0D%0A%5Cu27CA%0D%0A%5Cu27CE-%5Cu27D7%0D%0A%5Cu27DA-%5Cu27DF%0D%0A%5Cu27E0-%5Cu27E5%0D%0A%0D%0A%5Cu29B5-%5Cu29C3%0D%0A%5Cu29C4-%5Cu29C9%0D%0A%5Cu29CA-%5Cu29D0%0D%0A%5Cu29D1-%5Cu29D7%0D%0A%5Cu29DF%0D%0A%5Cu29E1%0D%0A%5Cu29E2%0D%0A%5Cu29E3-%5Cu29E6%0D%0A%5Cu29FA%0D%0A%5Cu29FB%0D%0A%0D%0A%5Cu2308-%5Cu230B%0D%0A%5Cu2336-%5Cu237A%0D%0A%5Cu2395%5D" target="_blank">650 code points</a> that your group identified by hand as operators. It also links to the combined <a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%5B%3ASm%3A%5D%5B%3ASo%3A%5D%5D" target="_blank">Sm and So categories</a>. However what you actually propose is the far-more-limited <a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7BBlock=Mathematical%20Operators%7D" target="_blank">Mathematical Operators block</a>.</div><div><br></div><div>I will take it upon myself to go through code-points by hand and see what I can find.</div><div><br></div><div>It is worth noting that your proposed “symbol identifier” category, by its very name, suggests it should have broader membership than just operators. I am not sure if that was intentional, however I will restrict my attention to symbols that may reasonably function as operators.</div><div><br></div><div>After a preliminary glance through the code blocks, I believe there are operator-like characters in <a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7BBlock%3DBasic+Latin%7D%0D%0A%5Cp%7BBlock%3DLatin-1+Supplement%7D%0D%0A%5Cp%7BBlock%3DGeneral+Punctuation%7D%0D%0A%5Cp%7BBlock%3DLetterlike+Symbols%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5Cp%7BBlock%3DMathematical+Operators%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Mathematical+Symbols-A%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Arrows-A%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Arrows-B%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Mathematical+Symbols-B%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Mathematical+Operators%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Symbols+and+Arrows%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Punctuation%7D&g=&i=" target="_blank">these blocks</a>:</div><div><div>Basic Latin</div><div>Latin-1 Supplement</div><div>General Punctuation</div><div>Letterlike Symbols</div><div>Arrows</div><div>Mathematical Operators</div><div>Miscellaneous Technical</div><div>Miscellaneous Mathematical Symbols-A</div><div>Supplemental Arrows-A</div><div>Supplemental Arrows-B</div><div>Miscellaneous Mathematical Symbols-B</div><div>Supplemental Mathematical Operators</div><div>Miscellaneous Symbols and Arrows</div><div>Supplemental Punctuation</div></div><div><br></div><div>Furthermore, <a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7BBlock%3DBox+Drawing%7D%0D%0A%5Cp%7BBlock%3DBlock+Elements%7D%0D%0A%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A%5Cp%7BBlock%3DDingbats%7D%0D%0A%5Cp%7BBlock%3DBraille+Patterns%7D%0D%0A%5Cp%7BBlock%3DCJK+Symbols+and+Punctuation%7D%0D%0A%5Cp%7BBlock%3DYijing+Hexagram+Symbols%7D%0D%0A%5Cp%7BBlock%3DAncient+Symbols%7D%0D%0A%5Cp%7BBlock%3DMusical+Symbols%7D%0D%0A%5Cp%7BBlock%3DTai+Xuan+Jing+Symbols%7D&g=&i=" target="_blank">the following blocks</a> *may* have symbols that we want to allow in operators:</div><div><div>Box Drawing</div><div>Block Elements</div><div>Geometric Shapes</div><div>Miscellaneous Symbols</div><div>Dingbats</div><div>Braille Patterns</div><div>CJK Symbols and Punctuation</div><div>Yijing Hexagram Symbols</div><div>Ancient Symbols</div><div>Musical Symbols</div><div>Tai Xuan Jing Symbols</div></div><div><br></div><div>I think that covers all the blocks with potentially operator-like characters. When I have had time to go through character by character I will report back my findings.</div></div></div></div></blockquote><div><br></div><div>A previous version of our proposal went through these blocks character-by-character. It was not a fruitful exercise, and absent a compelling use case, I would not recommend it, as Jonathan has made clear that whatever UAX#31 ends up doing, it's definitely the case that Unicode will not be adopting this character-by-character approach.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote"><div>Nevin</div><div><br></div><div> </div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sat, Oct 22, 2016 at 12:59 AM, Jonathan S. Shapiro via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">All:<div><br></div><div>Jacob has already identified a <i>big</i> hole in the proposal, which is that it doesn't define how operator-bound identifiers are treated by import. That definitely needs to be addressed by the proposal. It's straightforward, but easy to get wrong. I will address that early tomorrow.<div><br></div><div><br></div><div>Jonathan</div></div></div>
<br></div></div><span class="">______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>