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.
