Major performance problem with std.array.front()

[Vladimir Panteleev]

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/jlgfkxlrhlzdpwkpsrot@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.