> On Oct 19, 2016, at 1:46 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > > 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: > >> 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: >> >> [:S:] - [:Sc:] - [:xidcontinue:] - [:nfcqc=n:] & [:scx=Common:] - >> pictographics - emoji > > 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. > > 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. > > 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. >
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 funny. We don’t have to squash the joy out of everything. Russ
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
