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.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 27, 2016 at 19:35 Russ Bishop <<a href="mailto:xenadu@gmail.com">xenadu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 25, 2016, at 3:19 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_3490065312149553458Apple-interchange-newline gmail_msg"><div class="gmail_msg">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.</div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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.</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Russ</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Oct 25, 2016 at 00:41 Russ Bishop via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 24, 2016, at 9:43 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_3490065312149553458m_3851549435048188229Apple-interchange-newline"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 23, 2016, at 9:41 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_3490065312149553458m_3851549435048188229Apple-interchange-newline"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 18, 2016, at 11:34 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail_msg m_3490065312149553458m_3851549435048188229Apple-interchange-newline"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">Dear Swift-Evolution community,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The latest (perhaps final?) draft is available here:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> <a href="https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifier-and-operator-symbology.md" class="gmail_msg" target="_blank">https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/NNNN-refining-identifier-and-operator-symbology.md</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- 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.</div><div class="gmail_msg">- 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.</div><div class="gmail_msg">- As to conservatism, explicitly reserving “..” (for possible future language directions) seems reasonable to me. Are there any other similar things we should consider reserving?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- 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.</div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-Joe</div><br class="gmail_msg"></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I’m not sure that is true. Unicode gives the list: <a href="http://unicode.org/emoji/charts/full-emoji-list.html" class="gmail_msg" target="_blank">http://unicode.org/emoji/charts/full-emoji-list.html</a>. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> 👍🏼 == 👍 <span style="font-family:'Apple Color Emoji';font-size:20px" class="gmail_msg">🏼</span></div><div class="gmail_msg"> </div><div class="gmail_msg">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. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Russ</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">- 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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-Chris</div><div class="gmail_msg"><br class="gmail_msg"></div></div></div>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
</div></blockquote></div></div></blockquote></div>