Re: The face of Unicode support in the future

>
> We will support "\x{xxxx}" where xxxx is a hexadecimal number for a
> codepoint in the character encoding of the string.  The behavior is
> undefined when there's no xxxx codepoint in the encoding.
>
> We won't introduce something Unicode specific in the future Ruby.
> But it's OK for JRuby to restrict supporting encoding to Unicode.
>
>                                                         matz.

Is there opposition to a separate unicode string class, that would
coexist with the current byte-based string class?  I find a fixed-width
unicode-based string type to be much easier to deal with rather
than individual encodings.  With the byte-based system you would have to
worry about the language of the text in each string, and check
encodings before doing something like a string compare.


How will things like string[pos] be handled?  If the string is a
non-fixed-width encoding, ruby will have to start at the beginning of
the string each time to figure out which bytes you want to access.

IIRC in iso-2022-jp you can't even find character boundaries unless you
go back to the shift-in marker (UTF8 allows you to find boundaries   
easily).  Is each encoder library going to need to be smart about
encodings, like adding two iso-2022-jp strings together:

<shift-in>japanese<shift-out> + <shift-in>japanese<shift-out>

The <shift-out><shift-in> can be dropped in the middle.

Will "iso-2022-jp-string".size give the number of characters, not
counting the shift sequences?  Will a separate method be needed to give
you the size in raw bytes, if, e.g. you need to allocate space for
storage?

Wes