<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 19, 2016 at 4:09 AM, Benjamin Spratling 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>Some extremely short-sighted points about deleting my formal operators that are widely recognized as operators, and that I’ve spent months adding into my code.  Frankly, I just couldn’t upgrade until you put them back in.</div></div></div></blockquote><div><br></div><div>Benjamin:</div><div><br></div><div>The situation &quot;behind the scenes&quot; is that I&#39;ve been working with Mark Davis to add Unicode standard properties for operator start and operator continue character sets in Unicode UAX31. That&#39;s a process whose scope needs to be broader than just Swift, and it&#39;s something that Swift will want to be compatible with. I think the intention would be to adopt that new part of UAX31 as soon as practical, and I am hopeful that specification will meet your needs and objectives. If not, I&#39;d very much like to pick up that conversation with you offline to see how we can improve matters in UAX31.</div><div><br></div><div>The UAX31 discussion seems to be converging rapidly. The proposal here is to <i>temporarily</i> limit operator identifiers to the ASCII operator characters. This is mainly intended to provide a bridge solution until UAX31 changes can be published in draft form. One reason to take a temporary step back is to ensure that we do not unintentionally specify something now that will become incompatible as soon as the UAX31 draft emerges.<br></div><div><br></div><div>Changes to the operator identifier space are well-localized in the compiler implementation, and don&#39;t have any large-scale impact on later passes. They are one of the few kinds of compiler changes that can safely be made late in a development cycle. If this part of UAX31 converges as quickly as I expect, I think we can get that result reflected into Swift 4, and we can get a draft version implemented sooner.</div><div><br></div><div><br></div><div>Jonathan</div></div></div></div>