[swift-evolution] InternalString class for easy String manipulation

[Xiaodi Wu]

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.


On Thu, Aug 18, 2016 at 2:34 PM, Kenny Leung via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > 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
> >
> >
>
> _______________________________________________
> 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/20160818/73bcccfa/attachment.html>