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

[Chris Lattner]

> On Oct 20, 2016, at 7:03 AM, 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 <mailto: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.

I don’t think it is a goal to “prevent” or “limit” obfuscation.  Operator overloading and using weird symbols is inherently going to obfuscate code for some people, and if it were a goal, we’d prevent operator overloading entirely.  We can’t legislate in the language that code is readable and maintainable.  We need to trust people to use the tools the language provides in a sane way, and rely on team feedback and coding standards to set the norm in their environment.

Besides that, I think we’ve all seen code where it would be most honest to name a variable or function 💩.  That’s the sometimes sad reality of software, and Swift should aim to support honest expression of these realities. :-) :-)

-Chris


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