Major performance problem with std.array.front()

[Dicebot]

On Friday, 7 March 2014 at 16:18:06 UTC, Vladimir Panteleev wrote:
> On Friday, 7 March 2014 at 15:03:24 UTC, Dicebot wrote:
>> I don't like it at all.
>>
>> 1) It is a huge breakage
>
> Can we look at some example situations that this will break?

Any code that relies on countUntil to count dchar's? Or, to 
generalize, almost any code that uses std.algorithm functions 
with string?

>> and you have been refusing to do one even for more important 
>> problems.
>
> This is a fallacy.

Ok :)

>> 2) It is regression back to C++ days of 
>> no-one-cares-about-Unicode pain. Thinking about strings as 
>> character arrays is so natural and convenient that if 
>> language/Phobos won't punish you for that, it will be 
>> extremely widespread.
>
> Thinking about dstrings as character arrays is less flawed only 
> to a certain extent.

Sure. But I find this extent practical enough to make the 
difference. It is good compromise between perfectly correct (and 
very slow) string processing and having your program unusable 
with anything but basic latin symbol set.

>> Now real problems I see:
>>
>> 1) stuff like readText() returns char[] instead of requiring 
>> explicit default encoding
>>
>> 2) lack of convenient .raw property which will effectively do 
>> cast(ubyte[])
>>
>> 3) the fact that std.string always assumes unicode and never 
>> forwards to std.ascii for 
>> http://dlang.org/phobos/std_encoding.html#.AsciiString / 
>> ubyte[]
>
> I think these are fixable without breaking anything? So why not 
> go for it? The first two sound trivial (.raw can be an UFCS 
> property).

(1) will likely require deprecation (== breakage) of old 
interface, but yes, those are relatively trivial. It is just has 
not been important enough to me to spend time on pushing it. 
Still struggling to finish my template argument list proposal :(