[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Joe Groff]

> On Oct 24, 2016, at 10:40 PM, Russ Bishop <xenadu at gmail.com> wrote:
> 
>> 
>> On Oct 24, 2016, at 9:43 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Oct 23, 2016, at 9:41 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Oct 18, 2016, at 11:34 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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’m not sure that is true. Unicode gives the list: http://unicode.org/emoji/charts/full-emoji-list.html <http://unicode.org/emoji/charts/full-emoji-list.html>. 
> 
> If a platform can’t render the ZJW sequences it can render them as separate Emoji, but Swift can still treat that as the same identifier.
> 
>  👍🏼 == 👍 🏼
>  
> If you don’t have a font capable of displaying the character at all that isn’t any different from not having a Chinese font available. You should get the missing character glyph. The list of emoji base characters is not unrestricted - there is a specific and limited list of valid base characters that accept modifiers. 
> 
> If we wanted to go further and say that all Emoji modifiers are preserved and rendered if possible but not considered part of the identifier that would be OK with me. Same for variation selectors.

Good to hear that there's some work being done into standardizing emoji—this wasn't the case three years ago when we adopted the N1518 character set. If there's a Unicode standard we can cite for what constitutes an emoji, that'd be a good foundation for "supporting emoji" in Swift syntax, though as Xiaodi notes, implementations still vary quite a bit in what they present as emoji in practice, and the fact that unsupported emoji are allowed to rendered completely invisible is troubling.

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161025/999a4f15/attachment.html>