<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 19, 2016 at 1:31 PM, David Waite 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">The problem is that this set does not just contain mathematical operators, but includes among other examples  \u2205 (Empty Set) and \u221E (infinity).</div></blockquote><div><br></div><div>Both of which are perfectly reasonable symbols to include.</div><div><br></div><div>From a UAX31 standpoint, the practical problem is that operator symbols are going to get defined largely in terms of the existing symbol category. It&#39;s not going to be perfect. Traditionally, Unicode standards have been defined in terms of properties rather than blocks. I do think its worth asking whether &quot;mathematical symbols&quot; is too broad and we may wish to consider only &quot;mathematical operators&quot;. I&#39;ll take that up with Mark.</div><div><br></div><div>This is one reason that I was briefly exploring whether operator identifiers could actually be used as identifiers generally. The answer boils down to: &quot;not if operator symbols admit . (period)&quot;. Unfortunately, the existing Swift standard library is <i>already</i> using .</div><div><br></div><div>Even if we were prepared to slog through all of the math symbols one by one and decide which ones are operators, I&#39;m not convinced that the UAX31 effort would be prepared to adopt the result. Part of the problem is that it&#39;s not just about singleton code points. It&#39;s about codepoints that get combined into operator identifiers that are then interpreted as operators.</div><div><br></div><div><br></div><div>Jonathan</div></div></div></div>