<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="">Is there a compromise we can come up with, maybe? Allow emoji in identifiers, but freeze the set of allowed emoji to whatever the current version of the Unicode spec defines with the intention that 'automatic expansion' of the allowed character set to accommodate future emoji is a non-goal? (Does Unicode even provide a way to express "the set of emoji characters supported by Specific Unicode Specification X"?)<div class=""><br class=""></div><div class="">Austin<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 20, 2016, at 12:06 AM, Xiaodi Wu 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 style="white-space:pre-wrap" class="">Point well taken, but FWIW, there is a large difference between *you* expressing whimsy and committing the language to an open-ended series of continuous revisions for the sole purpose of enabling one particular form of whimsy. It's rather an overstatement to say that we are proposing to "squash the joy out of everything," as though we all lived our lives in states of ascetic deprivation before the advent of emoji.<br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Oct 20, 2016 at 14:38 Russ Bishop via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><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="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 19, 2016, at 1:46 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_-1386859220507008595Apple-interchange-newline"><div class="gmail_msg"><div class="gmail_msg">I was in the middle of writing about my opposition to the original proposal when I went to bed last night, and was going to advocate something like this:<br class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg">Given the current state of the discussion over in Unicode land, I think it would probably be safe from a compatibility standpoint to admit code points that fall into the following (Unicode-style) code point set:<br class="gmail_msg"><br class="gmail_msg">[:S:] - [:Sc:] - [:xidcontinue:] - [:nfcqc=n:] & [:scx=Common:] - pictographics - emoji<br class="gmail_msg"></blockquote><br class="gmail_msg">I suspect we can probably also do something about emoji, since I doubt UAX #31 is going to. Given that they are all static pictures of people or things, I think we can decide they are all nouns and thus all identifier characters. If we think there are some which might be declared operators later, we can exclude them for now, but I'd like to at least see the bulk of them brought in.<br class="gmail_msg"><br class="gmail_msg">I think addressing emoji is important not for any technical reason, but for nontechnical ones. Emoji are a statement about Swift's modern approach; modernity is important. They are fun and whimsical; whimsy is important.<br class="gmail_msg"><br class="gmail_msg">And most importantly, emoji identifiers are part of Swift's culture. It's widely understood that you don't use them in real code, but they are very common in examples. Just as we worry about source compatibility and binary compatibility, so we should worry about culture compatibility. Removing emoji would cause a gratuitous cultural regression.<br class="gmail_msg"><br class="gmail_msg"></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I fully agree. It’s hella presumptuous to decide that I’m not allowed to express whimsy, frustration, humor, or any other emotions in my code. Or to tell an 8 year old using Playgrounds on the iPad that he/she can’t name a variable 🐷 purely because they find it <i class="gmail_msg">funny</i>. We don’t have to squash the joy out of <i class="gmail_msg">everything</i>.</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Russ</div></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>