[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Xiaodi Wu]

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.

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:

[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]

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.

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.

On Wed, Oct 19, 2016 at 19:09 Benjamin Spratling via swift-evolution <
swift-evolution at swift.org> wrote:

Howdy,
Some good points about standardizing identifiers.
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.

Operators

Swift operator characters will be limited to only the following ASCII
characters:

! % & * + - . / < = > ? ^ | ~

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.

There’s just no good reason to make
≤ ≥ ≠ ±
not valid operators.

“in homage to Swift's origins, we permit 🐶 and 🐮 in identifiers."

That’s a blatant attempt at a cheat.  Wrong answer.

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.

- - From me

-Ben
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161019/f6d53cd9/attachment.html>