Major performance problem with std.array.front()

[Dmitry Olshansky]

08-Mar-2014 05:18, Andrei Alexandrescu пишет:
> On 3/7/14, 12:48 PM, Dmitry Olshansky wrote:
>> 07-Mar-2014 23:57, Andrei Alexandrescu пишет:
>>> On 3/6/14, 6:37 PM, Walter Bright wrote:
>>>> In "Lots of low hanging fruit in Phobos" the issue came up about the
>>>> automatic encoding and decoding of char ranges.
>>> [snip]
>>>
>>> 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.
>>
>> Special case was wrong though - special casing arrays of char[] and
>> throwing all other ranges of char out the window. The amount of code to
>> support this schizophrenia is enormous.
>
> I think this is a confusion. The code in e.g. std.algorithm is
> specialized for efficiency of stuff that already works.

Well, I've said it elsewhere - specialization was too fine grained. 
Either a generic or it doesn't work.

>
>>> Making strings bidirectional ranges has been a very good choice within
>>> the constraints. There was already a string type, and that was
>>> immutable(char)[], and a bunch of code depended on that definition.
>>
>> Trying to make it work by blowing a hole in the generic range concept
>> now seems like it wasn't worth it.
>
> I disagree. Also what hole?

Let's say we keep it.
Yesterday I had to write constraints like this:

if((isNarrowString!Range && is(Unqual!(ElementEncodingType!Range) == 
wchar)) ||
  (isRandomAccessRange!Range && is(Unqual!(ElementType!Range) == wchar)))

Just to accept anything that works alike to array of wchar, buffers and 
whatnot included.

I expect that this should have been enough:
isRandomAccessRange!Range && is(Unqual!(ElementType!Range) == wchar)

Or maybe introduce something to indicate any "DualRange" of narrow chars.

-- 
Dmitry Olshansky