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

[Jonathan S. Shapiro]

On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution <
swift-evolution at swift.org> wrote:

> Is there a compromise we can come up with, maybe?
>

So speaking just for myself, I strongly oppose emojis because every example
of emoji code I have seen has been truly obfuscated. Emojis therefore
present very serious and active source-level security risks that will
require significant engineering investment to manage and will never be
fully managed successfully.

That said, I'm very glad that some people here have pointed out the "kid
use case", because I had not considered that one. I think that's actually
pretty compelling.

Let me ask a question: would single-character emoji identifiers be enough,
or do we need multi-character emojis? Single-character emoji identifiers
would go a long way toward limiting the capacity for obfuscation, but I'm
guessing it won't be enough for a bunch of people here.


> Freeze the set of allowed emoji to whatever the current version of the
> Unicode spec defines...
>

UAX31 won't include emojis in either space, because there is no clear
consensus about where they belong (identifiers or operators). Individual
languages can certainly add them to one space or the other, but should take
care not to cross-contaminate. So if we add them to operators, we need to
exclude any that are already part of normal identifiers and vice versa.
That sanity restriction is technically necessary, but it shouldn't be an
inconvenience in practical terms.


Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161020/ed8d8cb5/attachment.html>