capwords is now scheduled for deprecation with no replacement as opposed
to scheduled for deprecation with capWords replacing it. Discussion on
the newgroup made it clear that capitalize does get some use, but no one
on the list seems to use capwords (going by recent questions about it
and when std.string was discussed back in January). So, I'm setting it
on the path to removal as opposed to renaming. capitalize gives the key
building block necessary for creating such a function yourself, so the
loss of functionality is minimal.
I also replaced the std.string constants which have the same name as the
their std.ctype counterparts so that code doesn't break which imports
both std.string and std.ctype.
indexOf and lastIndexOf should not work properly with unicode for all
string types (unlike before). As part of that, I also ended up fixing a
bug in std.array.back for strings (wstrings in particular were broken).
I also improved various, related unit tests.
rjustify and ljustify were renamed, and all of the justification
functions were updated to take on the filling ability of zfill, so
zfill is now scheduled for deprecation.
I'm not sure exactly what we want to do with hexDigits. I had originally
added the lowercase a-f to it on the theory that they're valid digits in
hex, but there's code in Phobos which uses std.string.hexdigits.length,
so I adjusted it so that hexDigits is the same as the old hexdigits but
added fullHexDigits for the version with the lowercase letters. Perhaps
folks will have something constructive to say about that in review, but
that's what I'm doing for now.
I added std.uni.isWhite, fixed the functions so that they returned bool
instead of int, and made a few other tweaks (including reformatting
some of the code which was nigh-on-unreadable with the very odd
indentation choices that had been made with it).
Unfortunately, the change from int to bool was made with the old
functions rather than with new ones, since the names were already good
for those functions. But the code breakage is likely to be minimal,
since the return values were always 1 or 0 and meant to be used as
boolean values. I expect that the code breakage from that will be
far smaller (possibly completely non-existent) than it would have been
to create new functions with different names which returned bool. And
since the names are good as they are, it wouldn't have been nice to
rename them anyway.
The delegate version isn't @safe, but that would require conditional
attributes and/or multiple overloads where the delegate is @safe,
@trusted, or @system. I'm not quite sure what it would take, so I'm
leaving it alone for now.
