> On Oct 20, 2016, at 7:03 AM, Jonathan S. Shapiro via swift-evolution > <[email protected]> wrote: > > On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution > <[email protected] <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
