<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 19:07, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div></blockquote><snip><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">There are a bunch of symbols in unicode which are hard to tell apart, and those are bad for recognition, and we should deal with that, but this proposal is throwing the baby out with the bathwater, then lighting the baby on fire. Honestly, I would propose we find a way to have Swift see certain classes of characters as identical. Can’t decide which of the thousand + symbols should be the one true + symbol? Have them all map to one of them. That emoji X symbol looks like X, so map it to X.</div></div></div></blockquote><br class=""></div><div><br class=""></div><div><div>Agreed.</div><div><br class=""></div><div>I really like the option of using unicode operators in swift. Removing them would be disappointing. But I do see the problem that there are a lot of redundancies and sources of confusion if there are no restrictions. Aside from the redundancies, some other cases that I find sub-optimal are: 'top-half of integral' <span style="color: rgb(51, 51, 51); font-family: 'Open Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px; background-color: rgb(249, 249, 249);" class="">⌠, </span><span style="color: rgb(51, 51, 51); font-family: 'Open Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif; background-color: rgb(249, 249, 249);" class="">and</span><span style="color: rgb(51, 51, 51); font-family: 'Open Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px; background-color: rgb(249, 249, 249);" class=""> </span> '<font color="#333333" face="Open Sans, Helvetica Neue, Helvetica, Arial, sans-serif" class=""><span style="background-color: rgb(255, 255, 255);" class="">left parenthesis upper hook</span><span style="background-color: rgb(255, 255, 255);" class=""><span style="font-size: 14px;" class="">’ </span></span></font><span style="background-color: rgb(255, 255, 255);" class=""><font color="#333333" face="Open Sans, Helvetica Neue, Helvetica, Arial, sans-serif" class=""><span style="font-size: 14px;" class="">⎛ ; </span>these<span style="font-size: 14px;" class=""> </span>don’t really seem like symbols we want to allow as operators. Perhaps *one* general rule here, is that symbols specifically meant for 2d math expressions aren't good candidates for inclusion, at least at the present. Another difficult one, I think, are the bracket-like glyphs. </font></span><span style="background-color: rgb(255, 255, 255);" class=""><font color="#333333" face="Open Sans, Helvetica Neue, Helvetica, Arial, sans-serif" class="">While these would be useful in certain math and physics related code, it’s not clear at the moment how these could be used in swift, until and unless </font></span><span style="background-color: rgb(255, 255, 255);" class=""><font color="#333333" face="Open Sans, Helvetica Neue, Helvetica, Arial, sans-serif" class="">some kind of ‘bracket overloading’ is made possible.</font></span><div class=""><br class=""></div><div class=""><div class="">I’m in favor of what Johnathan Hull has suggested above. I’m also in favor of what some others have suggested, i.e., restricting the allowed operator symbols to some uncontroversial subset, mainly from the unicode ‘math’ category of symbols, and then possibly adding more as needed.</div><div class=""><br class=""></div><div class="">-Matt</div></div></div></div><br class=""></body></html>