On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution < swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
