Major performance problem with std.array.front()

[Nick Sabalausky]

On 3/6/2014 11:11 PM, Nick Sabalausky wrote:
> What about this?:
>
> Anywhere we currently have a front() that decodes, such as your example:
>
>>    @property dchar front(T)(T[] a) @safe pure if (isNarrowString!(T[]))
>>    {
>>      assert(a.length, "Attempting to fetch the front of an empty array
>> of " ~
>>             T.stringof);
>>      size_t i = 0;
>>      return decode(a, i);
>>    }
>>
>
> We rip out that front() entirely. The result is *not* technically a
> range...yet! We could call it a protorange.
>
> Then we provide two functions:
>
> auto decode(someStringProtoRange) {...}
> auto raw(someStringProtoRange) {...}
>
> These convert the protoranges into actual ranges by adding the missing
> front() function. The 'decode' adds a front() which decodes into dchar,
> while the 'raw' adds a front() which simply returns the raw underlying
> type.
>
> I imagine the decode/raw would probably also handle any "length"
> property (if it exists in the protorange) accordingly.
>
> This way, the user is forced to specify "myStringRange.decode" or
> "myStringRange.raw" as appropriate, otherwise myStringRange can't be
> used since it isn't technically a range, only a protorange.
>
> (Naturally, ranges of dchar would always have front, since no decoding
> is ever needed for them anyway. For these ranges, the decode/raw funcs
> above would simply be no-ops.)
>

Of course, I just realized that these front()s can't be added unless 
there's already a front to be called in the first place...

So instead of ripping out the current front() functions entirely, we 
replace "front" with some sort of "rawFront" which the raw/decode 
versions of front() can query in order to provide actual 
decoding/non-decoding ranges.