Major performance problem with std.array.front()

Dmitry Olshansky dmitry.olsh at gmail.com
Fri Mar 7 12:48:19 PST 2014


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.

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

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list