On Saturday, 8 March 2014 at 20:50:49 UTC, Andrei Alexandrescu
wrote:
On 3/8/14, 12:38 PM, Vladimir Panteleev wrote:
On Saturday, 8 March 2014 at 20:05:36 UTC, Andrei Alexandrescu
wrote:
That sounds quite like C++ plus ICU. It doesn't strike me as
the
golden standard for Unicode integration.
Why not? Because it sounds like D needs exactly that. Plus its
amazing
slicing and range capabilities, of course.
Pretty much everyone using ICU hates it.
I admit I never used it personally. I just thought you meant that
implied "D implementations of relevant Unicode algorithms,
adapted to D style (range interface)". Is there more to this than
the limitations of C++ or the implementers' design choices?
Have you or anyone you personally know tried to process text
in D
containing a writing system such as Sanskrit's?
No. Point being?
Point being, we don't have solid data to conclude whether D's
current approach is actually good enough for such cases as you
claim.
We do have one post in this thread:
http://forum.dlang.org/post/jlgfkxlrhlzdpwkps...@forum.dlang.org
I think there are too large risks for that,
For what? We have not discussed a possible plan yet. Are you
referring to Walter Bright's proposal?
and it's quite unclear this is solving a problem. "Slightly
better Unicode support" is hardly a good justification.
What this will solve:
1. Eliminating dangerous constructs, such as s.countUntil and
s.indexOf both returning integers, yet possibly having different
values in circumstances that the developer may not foresee.
2. Very high complexity of implementations (the
ElementEncodingType problem previously mentioned).
3. Hidden, difficult-to-detect performance problems. The reason
why this thread was started. I've had to deal with them in
several places myself.
4. Encourage D programmers to write Unicode-capable code that is
correct in the full sense of the word.
I think the above list has enough weight to merit at least
considering *some* breaking changes.
