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

[Rien]

Said differently: A monkey with a tool is still a monkey.
I.e. Swift cannot force somebody to become a good programmer no matter what rules it imposes.
As far as limiting personal freedoms goes: everybody (kid’s included) should be able to use whatever pleases them - within the possibilities of the language.
But the language should not impose restrictions it does not need.
If somebody out there wants to use emoticons, or whole pages of them… so what?.
Any company or programmer worth its salt has their own rules for what constitutes a good identifier or operator.

OTOH: I would not go as far as in optimizing the compiler to deal with anything non-ascii. If people want to use emoticons, and this results in sub-par performance in compilation or execution speed, so be it.

Rien.

> On 20 Oct 2016, at 16:03, Jonathan S. Shapiro via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution