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

[Xiaodi Wu]

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?

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.

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.

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.

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.


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


> On Oct 19, 2016, at 7:18 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> How did you decide on those operators instead of ASCII ones?

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.

>  Obviously, we would want to enable as many operators as possible to
continue functioning.
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.

>       •       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?").

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.

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.

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.

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.

-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/7a036f5e/attachment-0001.html>