Major performance problem with std.array.front()

[Dmitry Olshansky]

07-Mar-2014 07:52, Walter Bright пишет:
> On 3/6/2014 7:06 PM, Walter Bright wrote:
>> On 3/6/2014 6:37 PM, Walter Bright wrote:
>>> Is there any hope of fixing this?
>>
>> Is there any way we can provide an upgrade path for this? Silent
>> breakage is
>> terrible. Any ideas?
>
> Ok, I have a plan. Each step will be separated by at least one version:
>
> 1. implement decode() as an algorithm for string types, so one can write:
>
>      string s;
>      s.decode.algorithm...
>
> suggest that people start doing that instead of:
>
>      s.algorithm...
>

This would also be a great fit in cases where 'decode' is decoding some 
other encoding.

> 2. Emit warning when people use std.array.front(s) with strings.
>
> 3. Deprecate std.array.front for strings.
>
> 4. Error for std.array.front for strings.

This sounds fine to me. I would even prefer to only offer explicit wrappers:
.raw - ubyte/ushort for UTF-8/UTF-16 etc.
.decode - dchars
as Nick suggests.

Then there is also the horrible ElementEncodingType vs ElementType.
I would love to see ElementEncodingType die.

>
> 5. Implement new std.array.front for strings that doesn't decode.

It would make it simple to think that strings are arrays of characters. 
This illusion was broken (and good thing it was), no point in 
reestablishing it to save a couple of keystrokes for those "who really 
know what they are doing".

-- 
Dmitry Olshansky