Major performance problem with std.array.front()

[Chris]

On Friday, 7 March 2014 at 03:52:42 UTC, Walter Bright wrote:
>
> 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...
>
> 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.
>
> 5. Implement new std.array.front for strings that doesn't 
> decode.

What about this:

[as above]
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...

[as above]
2. Emit warning when people use std.array.front(s) with strings.

3. Implement new std.array.front for strings that doesn't decode, 
but keep the old one either forever(ish) or until way into D3 
(3.03).

4. Deprecate std.array.front for strings (see 3.)
5. Error for std.array.front for strings. (see 3)

I know that one of the rules of D is "warnings should eventually 
become errors", but there is nothing wrong with waiting longer 
than a few months before something is an error or removed from 
the library, especially if it would cause loads of code to break 
(my own too, I suppose). As long as users are aware of it, they 
can start to make the transition in their own code little by 
little. In this case they will make the transition rather sooner 
than later, because nobody wants to suffer constant performance 
penalties. So for this particular change I'd suggest to wait 
patiently until it can finally be deprecated. Is this feasible?