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

[Xiaodi Wu]

On Fri, Oct 21, 2016 at 4:32 PM, Jonathan S. Shapiro <
jonathan.s.shapiro at gmail.com> wrote:

> On Fri, Oct 21, 2016 at 1:10 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> A few other thoughts:
>>
>> * One of our (or at least my) overarching goals for this proposal is to
>> refine identifier and operator sets by moving away from an ad-hoc
>> character-by-character approach to a systematic treatment that relies on
>> well-defined criteria to select blocks of characters for inclusion.
>>
>
> I completely agree with this, up to the point where you wrote "select
> blocks". That doesn't seem to be the way things are selected in the Unicode
> universe.
>
> We can choose to adopt blocks as an interim measure, but we should not
> loose sight of the notion that this should eventually be property-driven.
>
> * Particularly if the community insists on emoji being identifiers, we
>> will have to critically evaluate how to proceed on that in tandem with
>> operators, because there exist emojified operators and arrows, and certain
>> emoji are encoded in blocks that are otherwise symbols, which Unicode is
>> likely to deem as operators in the future.
>>
>
> This is not correct. The current view in the UAX31 discussion is that
> emojis and pictographics should be excluded from *both* types of
> identifiers so that individual programming languages can make
> language-specific choices.
>
> The main current problem is that there is no clear-cut Unicode property
> covering Emojis at the present time, which is something that needs to be
> resolved over in Unicode-land. There is a list given in the antique texty
> UCD file format, but it isn't part of the XML formulation of the UCD
> database. I'll be generating a proposed update shortly, and when I have
> that I can provide a working list in the form of a C file that can be used
> by Swift.
>
> I have a mild preference that emojis should live in conventional
> identifiers if they are adopted.
>
>
>>  Moreover, IIUC, certain codepoints can be either emoji or non-emoji
>> symbols and variant selectors can specify which they are...
>>
>
> Can you expand on this and (hopefully) point me at the appropriate spot in
> one of the Unicode TRs?
>

Indeed. This issue first popped up on my radar when John Gruber wrote that
he had issues with his website displaying the curly arrow symbol as emoji
in recent browsers:

https://twitter.com/gruber/status/590355262281744384

Turns out, certain characters have emoji variants and text variants, which
can be selected for explicitly by appending a variant selector:

http://mts.io/2015/04/21/unicode-symbol-render-text-emoji/

However, whether the *default* presentation in the absence of a variant
selector is text or emoji can change from platform to platform, or from use
case to use case. This is explicitly spelled out in UTR#51:

"The presentation of a given emoji character depends on the environment,
whether or not there is an emoji or text variation selector, and the
default presentation style (emoji vs text). In informal environments like
texting and chats, it is more appropriate for most emoji characters to
appear with a colorful emoji presentation, and only get a text presentation
with a text variation selector. Conversely, in formal environments such as
word processing, it is generally better for emoji characters to appear with
a text presentation, and only get the colorful emoji presentation with the
emoji variation selector."

http://unicode.org/reports/tr51/#Presentation_Style


>
>
> Thanks!
>
>
> Jonathan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161021/3251850a/attachment.html>