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.
