On Saturday, March 03, 2012 14:57:59 Piotr Szturmaj wrote: > This discrepancy pushes the range writer to handle special string cases.
Yes it does. And there's _no_ way around that if you want to handle unicode both correctly and efficiently. To handle it correctly, you must operate on code points (or even better, graphemes), but to handle them efficiently, you must take the encoding into account. Phobos has gone with the default of correctness while giving you the tools to special case stuff for efficiency. Phobos itself uses static if all over the place to special case pieces of functions on string type. Stuff like isNarrowString and ElementEncodingType exist specifically for that. > The problem with that range is when it takes a string type, it aliases > this type with itself, because ElementType!R yields dchar. This is why > I'm talking about "bad consequences", I just want to iterate string by > _char_, not _dchar_. If you want to iterate by char, then use foreach or use a wrapper range (or cast to ubyte[] and operate on that). Phobos specificically does not to do that, because it breaks unicode. It doesn't stop you from iterating by char or wchar if you really want to, but it operates or ranges of dchar by default, because it's more correct. - Jonathan M Davis
