Unicode handling comparison

[Jakob Ovrum]

On Wednesday, 27 November 2013 at 16:15:53 UTC, Wyatt wrote:
> I don't remember if it was brought up before, but this makes me 
> wonder if something like an i18nString should exist for cases 
> where it IS important.  Making i18n stuff as simple as it looks 
> like it "should" be has merit, IMO.  (Maybe there's even room 
> for a std.string.i18n submodule?)
>
> -Wyatt

What would it do that std.uni doesn't already?

i18nString sounds like a range of graphemes to me. I would like a 
convenient function in std.uni to get such a range of graphemes 
from a range of points, but I wouldn't want to elevate it to any 
particular status; that would be a knee-jerk reaction. D's 
granularity when it comes to Unicode is because there is an 
appropriate level of representation for each domain. Shoe-horning 
everything into a range of graphemes is something we should avoid.

In D, we can write code that is both Unicode-correct and highly 
performant, while still being simple and pleasant to read. To 
write such code, one must have a modicum of understanding of how 
Unicode works (in order to choose the right tools from the 
toolbox), but I think it's a novel compromise.