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?
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)!
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.
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.
> [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]
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.
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.
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…
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
