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
