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

[Xiaodi Wu]

Unfortunately, Joe is correct on this point. As I stated earlier in the
thread, there are a series of characters that can be either text or emoji
in presentation, where the default presentation differs depending on
platform, technology, use case, or context. This is also not a bug, but
explicitly contemplated by Unicode technical recommendations. You can
convince yourself of this fact by looking up the Wikipedia page on the
Unicode "dingbats" block and comparing the rendering on Safari on iOS and
Safari on macOS. You will see that they are different.

Unfortunately, you are incorrect about the behavior of missing glyphs.
Unlike, say, Chinese displayed on a machine without the necessary fonts,
there is a security concern that Unicode 9 emoji not yet supported by Apple
are non-displaying on that platform. No placeholder appears. This includes
what is according to Emojipedia the #1 most popular emoji, the shrug.
(Check out Emojipedia on a Mac.) It appears that there is no required
placeholder glyph for unsupported emoji, so any of them can legitimately
disappear on a non-supported platform. This is an issue worth serious
consideration.

Finally, the issue remains live as to whether we can have some way of
confronting the issue that Apple platforms now have emoji that differ both
in name and appearance from other platforms. In the latest version of macOS
Sierra, a wide swath of emoji have been renamed to diverge from Unicode
guidelines. Some, like "pile of poo" have been renamed only subtly ("pile
of poop"). However, others like "imp" have been completely renamed, so that
where formerly the Apple rendering was a stretch as compared to Unicode
recommendations, now Apple platforms are literally drawing and describing a
completely different thing at the same codepoint. We in the Swift community
obviously cannot tell Apple how to draw or name their emoji. But, Apple is
clearly willing to unilaterally revise arbitrary numbers of emoji in a
single release of their OS and may continue to do so. Is this appropriate
for programming language identifiers? I think not. But I can't square that
with the clear demand for emoji identifiers in the community.

On Tue, Oct 25, 2016 at 00:41 Russ Bishop via swift-evolution <
swift-evolution at swift.org> wrote:

> On Oct 24, 2016, at 9:43 AM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Oct 23, 2016, at 9:41 PM, Chris Lattner via swift-evolution <
> 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> 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
>
> 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.
>
> 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.
>
>
> Russ
>
>
> - 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161025/7f068cf7/attachment.html>