Major performance problem with std.array.front()

[Sean Kelly]

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.