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?
