Major performance problem with std.array.front()

[Dicebot]

On Friday, 7 March 2014 at 19:43:57 UTC, Walter Bright wrote:
> 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

Not important enough. D has always been "safe by default, fast 
when asked to" language, not other way around. There is no 
fundamental performance problem here, only lack of knowledge 
about Phobos.

> 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)

That may imply that better documentation is needed. You were only 
surprised because of wrong initial assumption about what `char[]` 
type means.

> 3. Weirdnesses like ElementEncodingType

ElementEncodingType is extremely annoying but I think it is just 
a side effect of more bigger problem how string algorithms are 
handled currently. It does not need to be that way.

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

Again, there is nothing strange about it. `char[]` is a special 
type with special semantics that is defined in documentation and 
consistently following  that definition in all but raw array 
indexing/slicing (which is what I find unfortunate but also 
beyond fixing feasibility).

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

Bad but not worth even a small breaking change.

>> 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.

Of course it is viral. Because you never ever wan't to have 
char[] at all if you don't work with Unicode (or work with it on 
raw byte level). And in that case it is your responsibility to do 
manual decoding when appropriate. Trying to dish out that 
performance often means going at low level with all associated 
risks, there is nothing special about char[] here. It is not a 
common use case.

> 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.

And this is how it should be. Again, I am all for creating 
language that favors performance-critical power programming needs 
over common/casual needs but it is not what D is and you have 
been making such choices consistently over quite a long time now 
(array literals that allocate, I will never forgive that). 
Suddenly changing your mind only because you have encountered 
this specific issue personally as opposed to just reports does 
not fit a language author role. It does not really matter if any 
new approach itself is good or bad - being unpredictable is a 
reputation damage D simply can't afford.