[swift-evolution] [Proposal] Refining Identifier and Operator Symbology
dev at xenonium.com
Thu Oct 20 01:46:21 CDT 2016
> Le 20 oct. 2016 à 02:11, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> a écrit :
> I actually take the opposite view of emoji, and I was convinced of this by arguments from some of the other authors (though they may not come to the same conclusions as I do):
> The real and very weighty reason Swift should support Unicode identifiers is that naming things is hard, and it is serious, and we should be adamant about this one thing:
> Even if your primary language is not English, and even if your use of Swift takes you beyond emulating the narrow set of standard library and Foundation API names, you can still take all the care and attention in naming things that we would want to promote in Swift by using your own primary language. We want this to be the case wherever you were born, whatever language your mother taught you, and we want to support this on principle, whether or not we can find empiric evidence of open-source projects on GitHub that make use of any particular language which we know to be used in the world.
> Previously, as we tackled this Unicode problem, a not-illegitimate critique was that Swift's support of Unicode identifiers appeared to be frivolous, because the only examples given in documentation are of emoji, and as you say, it is there to be cute or whimsical. This appearance undermines that very serious idea described above.
And removing emoji remove the possibility to write simple sample code using an universal language that is understandable whatever language your mother taught you. If you want to have a car variable or a dog variable, just use the emoji and everybody can read it without hesitation.
> UAX#31 makes room for the removal of obsolete scripts such as Egyptian hieroglyphics from the range of valid identifier characters on the basis (at least in my reading of the document) that it adds to the burden of a programming language without serving the weighty purpose of expressing themselves in their primary language. By analogy, emoji similarly do not serve that purpose, and since their parsing changes with every Unicode update, we would be making changes to Swift every minor release for the purpose of chasing a modish whimsy.
> On Thu, Oct 20, 2016 at 04:46 Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.
> Brent Royal-Gordon
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution