<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=""><div class="">An EXTREME -1 from me as well. The restrictions on operators is FAR too severe. At the very least, I need the upside-down question mark and exclamation points ¿ ¡, as well as the ≤,≥,≠ operators. I mean, you are getting rid of the division sign ÷. How could that ever be controversial as an operator?</div><div class=""><br class=""></div><div class="">This is the first proposal I have seen, where if it goes through, I will actually have to stop using Swift (or find a way not to upgrade)!</div><div class=""><br class=""></div><div class=""><div class="">Seriously, this proposal would break the vast majority of my code. One of the first things I wrote for Swift was a packrat parser which lets me define rulesets that look like standard PEG using swift operators. I have now written several different projects on top of that. I also have a private extension for ≤,≥,≠ that I use in my projects.</div></div><div class=""><br class=""></div><div class=""><div class="">What happened to needing extra justification for breaking changes? We can add them back later, you say. This seems to be breaking things just for the fun of it then…. If you are going to need to break things later to become compatible with something, then break them later. Don’t break my production code now to avoid a 1% chance you might have to break my production code in the future.</div></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">[begin quote]
• 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?").
• 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.
[end quote]</pre></blockquote><div class="">With all due respect, my day job is in the cognitive sciences (I have a master’s degree in Cognitive Psychology) and this is pure bullshit. The entire reason we use symbols is that the opposite is true. Yes, there is temporarily a greater burden on people who are new to a symbol, but once they learn it, it has much faster recall and recognition. That is why we use icons all over the place. It is why mathematicians use symbols. It is why you see all those symbols on signs at the airport.</div></div><div class=""><br class=""></div><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 class=""><br class=""></div><div class="">This proposal is lazy and unreasonable. I think we can all agree that there needs to be thought around confusable symbols… but most of us just aren’t using the confusable symbols. The argument seems to be “Let’s break EVERYTHING now so we don’t have to break it later”, which is pure ridiculousness. Don’t break anything now… and then when you are ready to deal with confusables (which, again, most people aren’t actually using) do it surgically then. You will be breaking a strictly smaller amount of code…</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>