<div style="white-space:pre-wrap">Sorry, I've not been very clear on my question. What non-ASCII operators are in use in your production code? What ASCII equivalents did you consider and discard for those particular operators?<br><br>It's important to remember that math *symbols* are not all operators. We cannot merely transpose Unicode characters labeled "mathematical" into our set of operators because many (such as the null set symbol) do not operate on anything and instead represent mathematical objects, which therefore suggests that if anything those should be valid identifier characters and not operator characters. This task becomes impossible once one considers that, in mathematics, symbols such as nabla are both used as operators _and_ may stand alone.<br><br>The bottom line is that this laborious work of classification is what the Unicode Consortium is for. I am convinced that we, the Swift community, are not capable of undertaking this task with any semblance of coherence. Jacob and I spent two or three emails going back and forth about the inclusion of "tiny" and "miny," two symbols I'll bet you've never contemplated using in your code. We also discussed whether pentagons and hexagons were appropriate (and yes, these are classed as mathematical symbols; on the one hand, these are plausibly operator-looking characters, but on the other hand, angles are not considered operators, and shapes can no more take an operand than can angles). Extending this work throughout the disparate ranges of mathematical symbols in Unicode 9 is untenable.<br><br>Note that while Unicode does not _yet_ have recommendations on operator characters, and while we cannot wait until it does in order to move forward, it is not out of the question that a future version of Swift could incorporate that work even if we remove non-ASCII characters today. However, if we move ahead with an ad-hoc selection of Unicode characters, we may never be able to converge with a future Unicode recommendation without breaking backwards source compatibility.<br><br>Thus, I think it's important to be specific about what code you can no longer write if non-ASCII operators are removed. It is not true that we have removed "almost every operator." Although we are proposing the removal of the vast majority of currently valid operator characters, based on our survey of code bases available to us, we believe that we are removing _zero or very nearly zero operators_ in usage today. Should you have a use case we haven't contemplated, I'd be very very keen to hear about it.</div><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Oct 19, 2016 at 21:06 Benjamin Spratling via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Oct 19, 2016, at 7:18 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br class="gmail_msg">
> How did you decide on those operators instead of ASCII ones?<br class="gmail_msg">
<br class="gmail_msg">
They are the “correct” mathematical symbols. On my machine, there is a block of characters explicitly marked as “Math Symbols". It’s a pretty good start (until you get to the section where latin characters are just drawn in different fonts,at which point, I make no assertions). ASCII is not the future. We have unicode for a reason, so we can type what we mean.<br class="gmail_msg">
<br class="gmail_msg">
> Obviously, we would want to enable as many operators as possible to continue functioning.<br class="gmail_msg">
I don’t find this statement to be consistent with the others. From my perspective, it looks like the proposal deleted as many operators as possible.<br class="gmail_msg">
<br class="gmail_msg">
> • Operators suffer from low discoverability and difficult readability. They use symbols, not names. This places a cognitive cost on users with respect to both recall ("What is the operator that applies the behavior I need?") and recognition ("What does the operator in this code do?").<br class="gmail_msg">
<br class="gmail_msg">
Requiring a developer to read “formUnion(with:)” is a large cognitive burden for someone trying to use Swift to solve problems in their field. Not all developers are only UI app makers or coding philosophers. Many are engineers and scientists trying to find a tool to get their job done. For these fields, using the correct mathematical operators significantly reduces the difficulty in reading code, which reduces the difficulty finding bugs. Swift offers a major performance improvement over the tools they may currently be using to get their jobs done, i.e. MatLab and Mathematica. While those tools offer other features Swift never will, there is always a push in research fields for better performance and independence from a desktop meta-tool, so battle tested algorithms are frequently moved out into stand-alone libraries. Yes, at times, that has been my job. Occasionally, someone working on advanced math libraries chimes in on the forum, I know there are folks working on vector libraries out there, I’m sure their code would be more legible using the correct vector-oriented operators. With the ascii-only operators, there is a lack of distinction between scalar products, and vector products, for example. Something which can be represented easily with extended unicode operators.<br class="gmail_msg">
<br class="gmail_msg">
If someone really wants to make the operator sets so restricted, fine, make that a policy at your company. Please don’t delete it from the language. In the course on Swift 3 that I’m teaching, I even recommend users don’t create operators they can’t easily type, but keyboards are going to get better. Heck, I’m paying as much for an Apple keyboard these days as I paid for a cell phone back in 2001.<br class="gmail_msg">
<br class="gmail_msg">
Look, go easy on me. I’m still reeling from discovering that weak references cause memory to be persisted until the app itself acts as a garbage collector. I was unable to bring myself to write code for 2 days following that. Please don’t take away my icing, too. I’m not sure I can keep writing code if you do. Removing standard math operators would make my code look I’m constantly writing 1980’s work arounds instead of clean code.<br class="gmail_msg">
<br class="gmail_msg">
I have a hard time accepting that essentially reverting the character set for Swift to ASCII is really a good move forward. I think the proposal reflects some good work on codifying identifiers, but I think the removal of emoji and almost every operator means there’s more work to be done before this proposal is ready for acceptance.<br class="gmail_msg">
<br class="gmail_msg">
-Ben<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>