<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 20, 2016, at 7:03 AM, Jonathan S. Shapiro via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Is there a compromise we can come up with, maybe?</div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>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. :-) :-)</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>