Re: Unicode implementation

> I just don't quite see why you are coming to the conclusion you have
> reached; that's why I asked for a concrete scenario.

The obvious nature of the problem should not require me to elaborate.
All right, a concrete problem.  Take strA and strB, perform

strC = strA[1000:1200] + strB[555:-204]

where the indices are Unicode characters (comprising 1-N code units
each) and negative indices count from the rear.

> True, but that doesn't mean that random access to code points is an
> important operation.

It is if:

> I do have to be cognizant of code point boundaries for many operations.

Which really means all of them. Strings are collections of letters.
Neither end users nor the programmers care about code units. A code
unit, qua code unit, is conceptually useless.

Consequently any string operation needs to be cognizant of letters,
not (merely) code units.

True, libraries can be (and have been) written to manipulate Unicode
strings in serialized format. There is nothing wrong with that. Nor is
there anything impressive in the statement that character boundaries
can be determined via string scanning. They can. It is just that this
particular case involves resistance to the idea of variable-width
characters, and string scanning time sinks, and the concept addresses
those issues.

The main question I had was whether anyone sees any particular reasons
coming out of Unicode that would pose problems for such an
implementation. So far I can see none, and indeed think it would lead
to significant performance gains for UTF-8.

Thanks, that's about all I have. It is getting to be more work talking
about this idea than it will be to write it...still I appreciate your interest everyone.

Mark