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

[Xiaodi Wu]

I actually take the opposite view of emoji, and I was convinced of this by
arguments from some of the other authors (though they may not come to the
same conclusions as I do):

The real and very weighty reason Swift should support Unicode identifiers
is that naming things is hard, and it is serious, and we should be adamant
about this one thing:

Even if your primary language is not English, and even if your use of Swift
takes you beyond emulating the narrow set of standard library and
Foundation API names, you can still take all the care and attention in
naming things that we would want to promote in Swift by using your own
primary language. We want this to be the case wherever you were born,
whatever language your mother taught you, and we want to support this on
principle, whether or not we can find empiric evidence of open-source
projects on GitHub that make use of any particular language which we know
to be used in the world.

Previously, as we tackled this Unicode problem, a not-illegitimate critique
was that Swift's support of Unicode identifiers appeared to be frivolous,
because the only examples given in documentation are of emoji, and as you
say, it is there to be cute or whimsical. This appearance undermines that
very serious idea described above.

UAX#31 makes room for the removal of obsolete scripts such as Egyptian
hieroglyphics from the range of valid identifier characters on the basis
(at least in my reading of the document) that it adds to the burden of a
programming language without serving the weighty purpose of expressing
themselves in their primary language. By analogy, emoji similarly do not
serve that purpose, and since their parsing changes with every Unicode
update, we would be making changes to Swift every minor release for the
purpose of chasing a modish whimsy.


On Thu, Oct 20, 2016 at 04:46 Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

I was in the middle of writing about my opposition to the original proposal
when I went to bed last night, and was going to advocate something like
this:

> Given the current state of the discussion over in Unicode land, I think
it would probably be safe from a compatibility standpoint to admit code
points that fall into the following (Unicode-style) code point set:
>
> [:S:] - [:Sc:] - [:xidcontinue:] - [:nfcqc=n:] & [:scx=Common:] -
pictographics - emoji

I suspect we can probably also do something about emoji, since I doubt UAX
#31 is going to. Given that they are all static pictures of people or
things, I think we can decide they are all nouns and thus all identifier
characters. If we think there are some which might be declared operators
later, we can exclude them for now, but I'd like to at least see the bulk
of them brought in.

I think addressing emoji is important not for any technical reason, but for
nontechnical ones. Emoji are a statement about Swift's modern approach;
modernity is important. They are fun and whimsical; whimsy is important.

And most importantly, emoji identifiers are part of Swift's culture. It's
widely understood that you don't use them in real code, but they are very
common in examples. Just as we worry about source compatibility and binary
compatibility, so we should worry about culture compatibility. Removing
emoji would cause a gratuitous cultural regression.

--
Brent Royal-Gordon
Architechies

_______________________________________________
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/20161020/517babf3/attachment.html>