Major performance problem with std.array.front()

[Walter Bright]

On 3/7/2014 7:03 AM, Dicebot wrote:
> 1) It is a huge breakage and you have been refusing to do one even for more
> important problems. What is about this sudden change of mind?

1. Performance Performance Performance

2. The current behavior is surprising (it sure surprised me, I didn't notice it 
until I looked at the assembler to figure out why the performance sucked)

3. Weirdnesses like ElementEncodingType

4. Strange behavior differences between char[], char*, and InputRange!char types

5. Funky anomalous issues with writing OutputRange!char (the put(T) must take a 
dchar)


> 2) lack of convenient .raw property which will effectively do cast(ubyte[])

I've done the cast as a workaround, but when working with generic code it turns 
out the ubyte type becomes viral - you have to use it everywhere. So all over 
the place you're having casts between ubyte <=> char in unexpected places. You 
also wind up with ugly ubyte <=> dchar casts, with the commensurate risk that 
you goofed and have a truncation bug.

Essentially, the auto-decode makes trivial code look better, but if you're 
writing a more comprehensive string processing program, and care about 
performance, it makes a regular ugly mess of things.