Major performance problem with std.array.front()

[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]
>>> Is there any hope of fixing this?
>>
>> There's nothing to fix.
>
> There is, all right. ElementEncodingType for starters.
>
>>
>> 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.

>> 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?


Andrei