Major performance problem with std.array.front()

[Vladimir Panteleev]

On Friday, 7 March 2014 at 19:57:38 UTC, Andrei Alexandrescu 
wrote:
> Allow me to enumerate the functions of std.algorithm and how 
> they work today and how they'd work with the proposed change. 
> Let s be a variable of some string type.

> s.canFind('é') currently works as expected.

No, it doesn't.

import std.algorithm;

void main()
{
     auto s = "cassé";
     assert(s.canFind('é'));
}

That's the whole problem - all this hot steam and it still does 
not work properly. Because it can't - not without pulling in all 
of the Unicode algorithms implicitly, and that would be much 
worse.

> I went down std.algorithm in the order listed in its 
> documentation and found pernicious issues with almost every 
> single algorithm.

All of your examples are variations of one and the same case: 
searching for a non-ASCII dchar or dchar literal.

How often does this pattern occur in real programs? I think the 
only real metric is to try the change and find out.

> Clearly one might argue that their app has no business dealing 
> with diacriticals or Asian characters. But that's the typical 
> provincial view that marred many languages' approach to UTF and 
> internationalization.

So is yours, if you think that making everything magically a 
dchar is going to solve all problems.

The TDPL example only showcases the problem. Yes, it works with 
Swedish. Now try it again with Sanskrit.