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

[Xiaodi Wu]

I'm not aware of any Unicode stipulations on rendering of unassigned code
points. In any case, Swift _n_ doesn't need to be designed around specific
platforms that exist in 2016, but it'd be perfectly sensible to say that
Swift 4 should restrict valid identifiers to those characters that are
displayed consistently on widely used platforms existing in 2016.

On Thu, Oct 27, 2016 at 19:35 Russ Bishop <xenadu at gmail.com> wrote:

> On Oct 25, 2016, at 3:19 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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.
>
>
> IMHO I don’t think Swift needs to be designed around rendering bugs with
> specific fonts on specific platforms. We can file a radar to have this
> corrected. I’m not aware of anything in Unicode that says it is acceptable
> to just drop unknown characters. I think some ZJW sequences or modifiers
> can be ignored; anything that can be ignored for rendering should be
> ignored for uniqueness of identifiers too.
>
>
> Russ
>
>
> 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/20161028/6f39f245/attachment.html>