> 18 Aug. 2016 07:40 Félix Cloutier via swift-evolution
> <swift-evolution@swift.org> 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.
Also, until quite recently "filesystem-friendly" meant "only uppercase
characters" and that only 8 (or on some systems only 6) characters could be
used. Maybe these ASCII proponents want us to write everything in uppercase as
well? And limit our identifiers to 6 characters. Now there's a proposal I can
get behind!
FUNC HLOWRL(S: STRING) -> STRING {
RETURN "HELLO, WORLD: \(S)"
}
Or, to take your example with "n" not being supported ("m" is pretty close both
phonetically and graphically):
FUMC HLOWRL(S: STRIMG) -> STRIMG {
RETURM "HELLO, WORLD: \(S)"
}
Still readable, right? And very easy for beginners.
/Magnus
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
