<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Even UTF-32 does not provide a 1-to-1 mapping to visual glyphs. As mentioned earlier in this thread, for instance, flags are composed of two Unicode characters.</div><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 18 août 2016 à 12:22:10, Jean-Denis Muys <<a href="mailto:jdmuys@gmail.com" class="">jdmuys@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">And both are variable-length encoding. I mean that different characters do<br class="">not necessarily occupy the same number of bytes in memory.<br class=""><br class="">But now, UTF-32 (or UCS-4) is a constant-length encoding. Why not using<br class="">UTF-32 as the encoding for an easy to use and easy to index string type?<br class="">The memory inefficiency of it might be a small price to pay in many cases,<br class="">including for beginners.<br class=""><br class="">Finally, I oppose restricting identifiers in Swift programs to ASCII chars<br class="">only. One reason is that in scientific programming, we at last can use<br class="">greek letters, or even: א.<br class=""><br class="">Jean-Denis<br class=""><br class=""><br class="">On Thu, Aug 18, 2016 at 8:51 PM, Félix Cloutier <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class="">wrote:<br class=""><br class=""><blockquote type="cite" class="">I'm not sure I understand your comment. UTF-8 and UTF-16 are just two<br class="">different ways to represent Unicode data, and they can both encode the<br class="">whole range of Unicode. Of course you'll have problems if you try to<br class="">interpret UTF-8 as UTF-16 and vice-versa, but that'll do you regardless of<br class="">whether you use international characters or not.<br class="">Félix<br class=""><br class=""><br class="">On Thursday, August 18, 2016 9:33 AM, Kenny Leung via swift-evolution <<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Just because you are using UTF-8 as the internal format, it does not<br class=""></blockquote></blockquote>mean that universal support is guaranteed.<br class=""><br class="">All I meant was this, and nothing more. If the internal format was UTF-8,<br class="">and you were using a filesystem whose filenames were UTF-16, you would have<br class="">the same problems.<br class=""><br class="">-Kenny<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Aug 17, 2016, at 10:40 PM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">In Félix’s case, I would expect to have to ask for a mail-friendly<br class=""></blockquote></blockquote>representation of his name, just like you have to ask for a<br class="">filesystem-friendly representation of a filename regardless of what the<br class="">internal representation is. Just because you are using UTF-8 as the<br class="">internal format, it does not mean that universal support is guaranteed.<br class=""><blockquote type="cite" class=""><br class="">Would you imagine if "n" turned out to be poorly supported by systems<br class=""></blockquote>throughout the world and dead-serious people argued that it's too hard for<br class="">beginners?<br class=""><blockquote type="cite" class=""><br class="">"Filesystem-friendly" and "email-friendly" names are not backed by<br class=""></blockquote>modern standards. You can have essentially any character that you like in a<br class="">file name save for the directory separator on almost every platform out<br class="">there (except on Windows, but the constraints are implemented in a layer<br class="">above NTFS), and addresses like félix@... are RFC-legal. Restrictions are<br class="">merely wished into existence by programmers who don't want to complicate<br class="">their mental model of text processing, to everyone else's detriment.<br class=""><blockquote type="cite" class=""><br class="">Félix<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class=""><br class=""></blockquote></div></div></blockquote></div><br class=""></body></html>