Major performance problem with std.array.front()

[Joseph Cassman]

On Sunday, 9 March 2014 at 01:23:27 UTC, Andrei Alexandrescu 
wrote:
>
> I was thinking of these too:
>
> 1. Revisit std.encoding and perhaps confer legitimacy to the 
> character types defined there. The implementation in 
> std.encoding is wanting, but I think the idea is sound. 
> Essentially give more love to various encodings, including 
> Ascii and "bypass encoding, I'll deal with stuff myself".
>
> 2. Add byChar that returns a random-access range iterating a 
> string by character. Add byWchar that does on-the-fly 
> transcoding to UTF16. Add byDchar that accepts any range of 
> char and does decoding. And such stuff. Then whenever one wants 
> to go through a string by code point can just use str.byChar.
>
>
> Andrei

I like these two points you make here. In particular, I like the 
recent addition of byGrapheme, and other ideas along this line 
which provide a custom range interface to a string. Such 
additions do not break code but add opt-in functionality for 
those who need it, while leaving the default case intact.

Overall, I think the current string design in D2 stikes a nice 
balance between performance and functionality. It does not reach 
Unicode perfection but gets rather close to good useability while 
still maintaining good C compatibility and performance in the 
default case.

As for Walter's original post regarding the use of decode by 
default in std.array.front, if I had it my way, I would prefer 
all performance hits to be explicit so that way I know what I am 
paying for by simply reading the code. Nonetheless, this change 
will break code in the wild relying on its current behavior. As a 
result, I feel that making such a fundamental change would be 
better to postpone until the next major version of D is 
considered. D currently seems to carry much hope due to its 
potential, but is struggling to gain reputation as a reliable, 
quality, production-ready language. If such fundamental changes 
are made at this point it will do a lot of harm to D's reputation 
which it may never recover from. Rather than making such a change 
now, I feel that fixing all open issues in bugzilla and 
'completing' D2 would do much good. Then, near the close of 
implementing D2, a new library implementation of text 
capabilities could be prototyped for D3 and flagged as 
beta-please-test-but-avoid-use-in-production-code. Such an 
approach would benefit from the insights gained from implementing 
this version in D2 and also get much needed input from actual 
usage.

Joseph