Major performance problem with std.array.front()

[Dmitry Olshansky]

09-Mar-2014 23:40, Andrei Alexandrescu пишет:
> On 3/9/14, 12:25 PM, Dmitry Olshansky wrote:
>> Okay putting potential breakage aside.
>> Let me sketch up an additive way of improving current situation.
>
> Now you're talking.
>
>> 1. Say we recognize any indexable entity of char/wchar/dchar, that
>> however has .front returning a dchar as a "narrow string". Nothing fancy
>> - it's just a generalization of isNarrowString. At least a range over
>> Array!char will work as string now.
>
> Wait, why is dchar[] a narrow string?

Indeed `...entity of char/wchar/dchar` --> `...entity of char/wchar`.

>> 3. ElementEncodingType is too verbose and misleading. Something more
>> explicit would be useful. ItemType/UnitType maybe?
>
> We're stuck with that name.

Too bad, but we have renamed imports... if only they worked correctly. 
But let's not derail.

[snip]

Great, so this may be turned into smallish DIP or bugzilla enhancements.

>> 6. Take into account ASCII and maybe other alphabets? Should be as
>> trivial as .assumeASCII and then on you march with all of std.algo/etc.
>
> Walter is against that. His main argument is that UTF already covers
> ASCII with only a marginal cost

He certainly doesn't have things like case-insensitive matching or 
collation on his list. Some cute tables are what "directly to the UTF" 
algorithms require for almost anything beyond simple-minded "find me a 
substring".

Walter certainly would have different stance the moment he observe the 
extra bulk of object code for these.

> (that can be avoided)

How? I'm not talking about  `x < 0x80` branches, these wouldn't cost a dime.

I really don't feel strong about 6th point. I see it as a good idea to 
allow custom alphabets and reap performance benefits where it makes 
sense, the need for that is less urgent though.

> and that we should
> go farther into the future instead of catering to an obsolete
> representation.

That is something I agree with.

-- 
Dmitry Olshansky