Major performance problem with std.array.front()

[Sean Kelly]

On Saturday, 8 March 2014 at 00:22:05 UTC, Walter Bright wrote:
> Andrei suggests that this change would destroy D by breaking 
> too much existing code. He might be right. Can we afford the 
> risk that he is right?

Perhaps not.  But I think the current approach is totally broken, 
it's just also happens to be what people have coded to.  Andrei 
used algorithms operating on a code point level as an example of 
what would break if this change were made, and in that he's 
absolutely correct.  But what bothers me is whether it's 
appropriate to perform this sort of character-based operation on 
Unicode strings in the first place.

The current approach is a cut above treating strings as arrays of 
bytes for some languages, and still utterly broken for others.  
If I'm operating on a right to left language like Hebrew, what 
would I expect the result to be from something like countUntil?  
And how useful would such a result be?  I'm inclined to say that 
the correct approach is to state that algorithms operate 
explicitly on a T.sizeof basis and that if the data contained in 
a particular range has some multi-element encoding then separate, 
specialized routines should be used with the T.sizeof behavior 
will not produce the desired result.

So the problem to me is that we're stuck not fixing something 
that's horribly broken just because it's broken in a way that 
people presumably now expect.  I'd personally like to see this 
fixed and I think the new behavior is preferable overall, but I 
do share Andrei's concern that such a big change might hurt the 
language anyway.