>> 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 <felix...@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@... 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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
