[swift-evolution] InternalString class for easy String manipulation

[Kenny Leung]

> On Aug 18, 2016, at 11:51 AM, Félix Cloutier <felixcca at yahoo.ca> wrote:
>  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.

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.

-Kenny


> On Thursday, August 18, 2016 9:33 AM, Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> >> Just because you are using UTF-8 as the internal format, it does not mean that universal support is guaranteed.
> 
> 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.
> 
> -Kenny
> 
> 
> > On Aug 17, 2016, at 10:40 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> > 
> >> 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.
> > 
> > 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?
> > 
> > "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 at ... 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.
> > 
> > Félix
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
>