<div dir="ltr">Actually, if I'm not mistaken, String (or at least, CFStringRef, to which String is toll-free bridged) does not re-encode anything eagerly. If you initialize with UTF8 bytes, it's stored internally as UTF8 bytes; if you initialize with UTF16 code units, it's stored internally as UTF16 code units. Re-encoding happens only when necessary--i.e. when you ask for UTF8 bytes from a UTF16-encoded string.<div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 18, 2016 at 2:34 PM, Kenny Leung via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Aug 18, 2016, at 11:51 AM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca">felixcca@yahoo.ca</a>> wrote:<br>
> Of course you'll have problems if you try to interpret UTF-8 as UTF-16 and vice-versa, but that'll do you regardless of whether you use international characters or not.<br>
<br>
</span>This is exactly my point. Even if the internal representation is UTF-8 (or UTF-16), you are not free from having to do conversions. You still need to convert to the encoding format that is understood by the receiver. I make a distinction between Unicode and Unicode encodings.<br>
<br>
-Kenny<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Thursday, August 18, 2016 9:33 AM, Kenny Leung via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
> >> Just because you are using UTF-8 as the internal format, it does not mean that universal support is guaranteed.<br>
><br>
> All I meant was this, and nothing more. If the internal format was UTF-8, and you were using a filesystem whose filenames were UTF-16, you would have the same problems.<br>
><br>
> -Kenny<br>
><br>
><br>
> > On Aug 17, 2016, at 10:40 PM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca">felixcca@yahoo.ca</a>> wrote:<br>
> ><br>
> >> In Félix’s case, I would expect to have to ask for a mail-friendly representation of his name, just like you have to ask for a filesystem-friendly representation of a filename regardless of what the internal representation is. Just because you are using UTF-8 as the internal format, it does not mean that universal support is guaranteed.<br>
> ><br>
> > Would you imagine if "n" turned out to be poorly supported by systems throughout the world and dead-serious people argued that it's too hard for beginners?<br>
> ><br>
> > "Filesystem-friendly" and "email-friendly" names are not backed by modern standards. You can have essentially any character that you like in a file name save for the directory separator on almost every platform out there (except on Windows, but the constraints are implemented in a layer above NTFS), and addresses like félix@... are RFC-legal. Restrictions are merely wished into existence by programmers who don't want to complicate their mental model of text processing, to everyone else's detriment.<br>
> ><br>
> > Félix<br>
><br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
><br>
><br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div>