> On Oct 23, 2016, at 9:41 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > >> On Oct 18, 2016, at 11:34 PM, Jacob Bandes-Storch via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Dear Swift-Evolution community, >> >> A few of us have been preparing a proposal to refine the definitions of >> identifiers & operators. This includes some changes to the permitted Unicode >> characters. >> >> The latest (perhaps final?) draft is available here: >> >> >> https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifier-and-operator-symbology.md >> >> <https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifier-and-operator-symbology.md> >> >> We'd welcome your initial thoughts, and will probably submit a PR soon to >> the swift-evolution repo for a formal review. Full text follows below. > > I haven’t had a chance to read the entire proposal, nor the tons of great > discussion down thread, but here are a few thoughts, just MHO: > > - I’m loving that you’re taking a detail oriented approach to the problem. I > agree with you that our current approach is unprincipled, and we need to get > this right for Swift 4. > - I think that it is perfectly fine to err on the side of conservatism: if it > isn’t clear how to classify something (e.g. Braille patterns), we should just > reject them in both operators and identifiers (make them be unassigned). If > these unclear cases are important to someone, then we can consider (as a > separate additive proposal) adding them back later. > - As to conservatism, explicitly reserving “..” (for possible future language > directions) seems reasonable to me. Are there any other similar things we > should consider reserving? > > - I applaud the creativity keeping 🐶🐮 a valid identifier :-), but it is > really missing the point. *All* of the non-symbol-like emoji’s should be > valid in identifiers. With a quick unscientific look at Apple’s character > picker, all the emojis other than a few in “Symbols” seem like they should be > identifiers. It would be fine to conservatively leave all emoji “symbols” as > unassigned.
The problem with this is that "emoji" is not a well-defined category by Unicode. Whether a character is rendered as emoji or a traditional symbol in a given font on a given platform can depend on variation selectors, and the exact variation selectors (or lack thereof) that choose emoji or traditional representation are non-portable, even among different text rendering APIs on the same platform (e.g. ATSUI vs TextKit vs CoreText vs WebKit on Darwin). -Joe > - I really think we should keep symbols as operators, including much of the > math symbols (e.g. ∪). In a later separate proposal, we can consider whether > it makes sense for emoji symbols (like ✖️to be usable as operators), I can > see arguments both ways. > > -Chris > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
