VLERange: a range in between BidirectionalRange and

[Steven Schveighoffer]

On Sat, 15 Jan 2011 14:51:47 -0500, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> I feel like you might be exaggerating, but maybe I'm completely wrong on  
> this, I'm not well-versed in unicode, or even languages that require  
> unicode.  The clear benefit I see is that with a string type which  
> normalizes to canonical code points, you can use this in any algorithm  
> without having it be unicode-aware for *most languages*.  At least, that  
> is how I see it.  I'm looking at it as a code-reuse proposition.
>
> It's like calendars.  There are quite a few different calendars in  
> different cultures.  But most people use a Gregorian calendar.  So we  
> have three options:
>
> a) Use a Gregorian calendar, and leave the other calendars to a 3rd  
> party library
> b) Use a complicated calendar system where Gregorian calendars are  
> treated with equal respect to all other calendars, none are the default.
> c) Use a Gregorian calendar by default, but include the other calendars  
> as a separate module for those who wish to use them.
>
> I'm looking at my proposal as more of a c) solution.
>
> Can you show how normalization causes subtle bugs?

I see from Michel's post how normalization automatically can be bad.  I  
also see that it can be wasteful.  So I've shifted my position.

Now I agree that we need a full unicode-compliant string type as the  
default.  See my reply to Michel for more info on my revised proposal.

-Steve