Several deprecated items were listed for removal in August, but it's
looking likely that 2.060 will come out in August, and I'd prefer not to
have them removed for 2.060 given how many items are already in the
changelog, and they're already deprecated, so it'll only affect people
compiling with -d either way. So, I'm changing the ddoc comments to say
September instead of August. They'll be removed in 2.061.
I decided to improve the documentation for some of std.string's
functions and ended up optimizing their implementations as well (I
benchmarked the new versions against the old versions, so they should
definitely be faster). I also ran into bug# 8323, so I fixed it as well.
I created an adjusted version of translate which is ASCII-only and
renamed maketrans to makeTrans with some minor changes. Instead of
deprecating the old translate and maketrans, maketrans is now a
deprecated alias of makeTrans, and the new ASCII-only translate should
be compatible with the old one.
Having the January deprecations and February deprecations in the same
month seems a bit much to me, since we managed to have both of those
months have quite a few, whereas the next few months have very few if
any. And we're close to release too, so I'd prefer to avoid causing
issues by deprecating them now.
The pragmas have not been as effective as we might have liked, since
they only work with templates and can't tell you where in your code you
need to make changes, and they seemed to have been more annoying to
programmers than helpful, so we're going to discontinue them. We'll
leave them in for stuff that's actually been deprecated until deprecated
has been improved enough to take a message, but we'll leave "scheduled
for deprecation" messages to the documentation and changelog.
isWhite, isLower, isUpper, toLower, and toUpper now have Ascii in their
name, which matches what std.unit does with its versions of those
functions. Hopefully, it should also reduce bugs due to using the wrong
function between the ASCII and unicode versions by making the difference
more obvious.
There was no consenus in the newsgroup about what to do about renaming
toStringz to be properly camelcased. It was pretty much divided between
renaming it to toCString and leaving it exactly as-is. No one wanted it
to be toStringZ. So, given the lack of consensus, I'm just going to
leave it as toStringz.
