Flexible string representation, unicode, typography, ...

[Ian Kelly]

On Sun, Aug 26, 2012 at 12:59 AM,  <wxjmfauth at gmail.com> wrote:
> Sorry, you do not get it.
>
> The rune is an alias for int32. A sequence of runes is a
> sequence of int32's. Go do not spend its time in using a
> machinery to work with, to differentiate, to keep in memory
> this sequence according to the *characers* composing this
> "array of code points".
>
> The message is even stronger. Use runes to work comfortably [*]
> with unicode:
> rune -> int32 -> utf32 -> unicode (the perfect scheme, cann't be
> better)

I understand what rune is.  I think you've missed my complaint, which
is that although rune is the basic building block of Unicode strings
-- representing a single Unicode character -- strings in Go are not
built from runes but from bytes.  If you want to do any actual work
with Unicode strings, then you have to first convert them to runes or
arrays of runes.  The conceptual cost of this is that the object
you're working with is no longer a string.

You call this the "perfect scheme" for working with Unicode.  Why does
the "perfect scheme" for Unicode make it *easier* to write buggy code
that only works for ASCII than to write correct code that works for
all characters?  This is IMO where Python 3 gets it right.  When you
want to work with Unicode strings, you just work with Unicode strings
-- none of this nonsense of first explicitly converting the string to
an array of ints that looks nothing like a string at a high level.
The only place Python 3 makes you worry about converting strings is at
the boundaries of your program, where decoding from bytes to strings
and back is necessary.