Major performance problem with std.array.front()

[Dmitry Olshansky]

08-Mar-2014 19:33, Andrei Alexandrescu пишет:
> On 3/8/14, 12:14 AM, Dmitry Olshansky wrote:
>> 08-Mar-2014 12:09, Dmitry Olshansky пишет:
>>> 08-Mar-2014 05:23, Andrei Alexandrescu пишет:
>>>> On 3/7/14, 1:58 PM, Vladimir Panteleev wrote:
>>>>> On Friday, 7 March 2014 at 21:56:45 UTC, Eyrk wrote:
>>>>>> On Friday, 7 March 2014 at 20:43:45 UTC, Vladimir Panteleev wrote:
>>>>>>> No, it doesn't.
>>>>>>>
>>>>>>> import std.algorithm;
>>>>>>>
>>>>>>> void main()
>>>>>>> {
>>>>>>>    auto s = "cassé";
>>>>>>>    assert(s.canFind('é'));
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>> Hm, I'm not following? Works perfectly fine on my system?
>>>>>
>>>>> Something's messing with your Unicode. Try downloading and compiling
>>>>> this file:
>>>>> http://dump.thecybershadow.net/6f82ea151c1a00835cbcf5baaace2801/test.d
>>>>
>>>> Yup, the grapheme issue. This should work.
>>>>
>>>> import std.algorithm, std.uni;
>>>>
>>>> void main()
>>>> {
>>>>      auto s = "cassé";
>>>>      assert(s.byGrapheme.canFind('é'));
>>>> }
>>>>
>>>> It doesn't compile, seems like a library bug.
>>>
>>> Becasue Graphemes do not auto-magically convert to dchar and back? After
>>> all they are just small strings.
>>>
>>>>
>>>> Graphemes are the next level of Nirvana above code points, but that
>>>> doesn't mean it's graphemes or nothing.
>>>>
>>
>> Plus it won't help the matters, you need both "é" and "cassé" to have
>> the same normalization.
>
> Why? Couldn't the grapheme 'compare true with the character?

Iff it consists of one codepoint, it technically may.

> I.e. the
> byGrapheme iteration normalizes on the fly.

Oh crap, please no. It's not only _Slow_ but it's also horribly 
complicated (even in off-line, eager version). + there are 4 
normalizations, of which 2 are lossy.

You simply can't be serious on this one, though seeing that you 
introduced auto-decoding then by extension you must have proposed to 
normalize on the fly :)


-- 
Dmitry Olshansky