Unicode handling comparison

[Dmitry Olshansky]

27-Nov-2013 22:12, H. S. Teoh пишет:
> On Wed, Nov 27, 2013 at 10:07:43AM -0800, Andrei Alexandrescu wrote:
>> On 11/27/13 7:43 AM, Jakob Ovrum wrote:
>>> On that note, I tried to use std.uni to write a simple example of how
>>> to correctly handle this in D, but it became apparent that std.uni
>>> should expose something like `byGrapheme` which lazily transforms a
>>> range of code points to a range of graphemes (probably needs a
>>> `byCodePoint` to do the converse too). The two extant grapheme
>>> functions, `decodeGrapheme` and `graphemeStride`, are *awful* for
>>> string manipulation (granted, they are probably perfect for text
>>> rendering).
>>
>> Yah, byGrapheme would be a great addition.
> [...]
>
> +1. This is better than the GraphemeString / i18nString proposal
> elsewhere in this thread, because it discourages people from using
> graphemes (poor performance) unless where actually necessary.

I could have sworn we had byGrapheme somewhere, well apparently not :(

BTW I believe that GraphemeString could still be a valuable addition. I 
known of at least one good implementation that gives you O(1) grapheme 
access with nice memory footprint numbers. It has many benefits but the 
chief problem with it:
a) It doesn't at all solve the interchange at all - you'd have to encode 
on  write/re-code on read
b) It relies on having global shared state across the whole program, and 
that's the real show-stopper thing about it

In any case it's a direction well worth exploring.
>
>
> T
>


-- 
Dmitry Olshansky