<div style="white-space:pre-wrap">Well, this is a very valuable contribution to the discussion. What non-ASCII operators are you currently using in Swift code? How did you decide on those operators instead of ASCII ones? Obviously, we would want to enable as many operators as possible to continue functioning.<br><br>There is, however, a very strong argument for restricting operator characters to ASCII. I'm going to quote from Erica Sadun, who's put this much better than I can:<br><br>[begin quote]<br><br> • 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> • This cost is obviously highest when symbols are not tied to conventional standards like `∪` for union and `⊇` for superset. `∪` is a standard, mathematical representation. It’s widely accepted and widely used. Even so, recognizing `formUnion(with:)` may work better for many coders than recalling what the `∪` (or, worse, `⊇`) operator does, even when you end up having to create suites of specialized selectors. As operators become more self-defined or esoteric, costs rise.<br><br>[end quote]<br><br>As to your specific example, there are indeed good reasons why it is not unreasonable to jettison support for, say, less-than-or-equal-to. For one, even if you have a configurable keyboard, every reasonable keyboard that could have the less-than-or-equal-to symbol will also have < and =, and <= is the standard operator in Swift for that concept.<br><br>As for emoji, their not being included is based on the reasoning that they are not required to support any real-world language; removal of "moof" is not a dealbreaker.<br></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Oct 19, 2016 at 19:09 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"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Howdy,</div><div class="gmail_msg">Some good points about standardizing identifiers.</div><div class="gmail_msg">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><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="m_265218756894062030m_-9006403917380313718m_5638394296234006553m_-8649013965328655554gmail_signature gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><h3 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;font-size:1.25em;line-height:1.25;color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol'" class="gmail_msg">Operators</h3><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px" class="gmail_msg">Swift operator characters will be limited to <span style="box-sizing:border-box;font-weight:600" class="gmail_msg">only</span> the following ASCII characters:</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px" class="gmail_msg">! % & * + - . / < = > ? ^ | ~</p></div></div></div></div></div></blockquote></div></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">For a mathematician / scientist / engineer, they have an easier time catching errors when the code on their screen look more like what they write on paper. Hence the only good reasons to leave sin() as a global function instead of a computed property. Obviously, we don’t have 2D layout in Swift, but finally using the right operator characters instead of the ridiculous ascii hacks was a breath of fresh air Swift breathed into my code. The state of operators in C languages was abysmal, and its legacy is still here. Take the blinders off for a moment and realize that “repetition” isn’t a great semantic: “&&” and “===“. They're a side effect of the hardware & character encoding sets available to developers in past decades, not a goal for the future. Sure, we don’t have screens on every key so I can set up my own domain specific operator character sets without having to scroll through a giant list of unused characters, but finally the second barrier had fallen. And at least there are prototypes and rumors of those keyboards out in the wild.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There’s just no good reason to make</div><div class="gmail_msg">≤ ≥ ≠ ± </div><div class="gmail_msg">not valid operators.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">“<span style="color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px" class="gmail_msg">in homage to Swift's origins, we permit </span><span style="color:rgb(51,51,51);box-sizing:border-box;font-family:'apple color emoji','segoe ui','segoe ui emoji','segoe ui symbol';font-size:21px;line-height:20px;vertical-align:middle;margin-right:0px" class="gmail_msg">🐶</span><span style="color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px" class="gmail_msg"> and </span><span style="color:rgb(51,51,51);box-sizing:border-box;font-family:'apple color emoji','segoe ui','segoe ui emoji','segoe ui symbol';font-size:21px;line-height:20px;vertical-align:middle;margin-right:0px" class="gmail_msg">🐮</span><span style="color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,'segoe ui',helvetica,arial,sans-serif,'apple color emoji','segoe ui emoji','segoe ui symbol';font-size:16px" class="gmail_msg"> in identifiers.</span>"</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">That’s a blatant attempt at a cheat. Wrong answer.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It’s true there are inconsistencies of the choice of whether a particular symbol is an operator or identifier, but I’d rather resolve that instead of blow everything away.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- - From me</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-Ben</div></div>_______________________________________________<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>