I'll admit that I'm probably not the best person to make
suggestions here. As a back-end programmer, a large portion of my
work is dealing with text streams of various types. And the data
I work with is in any number of encodings and none can be assumed
to be in English. But literally all of my work is either parsing
protocols where the symbols are single byte and so the C way is
appropriate, or they are with blocks of text where I basically
never work at the per character level. In fact I can think of
only one case--trimming a block of text for disay in a small
frame. And there I use an explicit routine for trimming to a
specific number of Unicodw characters.
So regarding std.algorithm, I couldn't use it because I need to
be able to slice based on the result. Knowing the number of
multibyte code points between the beginning of the string and the
thing I was searching for is utterly useless. Also, the
performance is way too bad to make it a consideration.
But you're right. I was being dramatic when I called it utterly
broken. It's simply not useful to me as-is. The solution for me
is fairly simple though if inelegant--cast the string to an array
of ubyte. Having both options is nice I suppose. I just can't
comment on the utility of the default behavior because I can't
imagine a use for it.
