Hi,
Daniel Micay and I have started doing some broad changes to the
std::vec and std::str modules, which will break things. Background:
the str and vec modules are/were 9000 lines of repetitive and crufty
code, with a lot of internal iterators and other "helper" functions
called once or twice in the whole rustc code base... all these
functions make the docs huge and horrible to navigate and generally
cause bloat.
# Iterators
With external iterators pretty much ready for prime-time[iterators],
str and vec have had a makeover: almost all iteration can and should
be done via the shiny new external iterators (most simply .iter() and
.rev_iter() for vecs and strings, along with others, like mutable
iterators and bytewise iterators), e.g.
use std::iterator::IteratorUtil;
...
for [1,2,3,4].iter().enumerate().advance |(i, &elem)| {
println(fmt!("%u-th element is %u", i, elem));
}
This looks a ugly (the `use` is required because IteratorUtil methods
names conflict with other methods[use], and there is a proposal for
dramatic improvement by making `for` more flexible[for]), but these
iterators can dramatically reduce the number of allocations required:
e.g. with external iterators there's rarely a need to .push onto a
new vector to collect values for later use, since one can express
transformations as a chain of method calls (and if one does need the
values in a vec, a call to .collect() is all that's needed, possibly
with a type annotation).
On this point, most iterating functions (i.e. each_...) have been
either removed or merged, since there are general iterator adaptors
in std::iterator for them (and more!), accessible via the
IteratorUtil trait. E.g.
vec::foldl(start, vec, f) => vec.iter().fold(start, f)
vec::foldr(start, vec, f) => vec.rev_iter().fold(start, |x, y| f(y, x))
str::all(string, |c| char::is_lowercase(c)) => string.iter().all(|c|
char::is_lowercase(c))
str::each_split_char(string, 'c', f) =>
string.split_iter('c').advance(f)
str::each_split(string, |c| c == 'b', f) => string.split_iter(|c:
char| c == 'b').advance(f)
(These last two are pending[pending pull], and, yes, that is the same
method. Currently only overloaded for char and &fn(char) -> bool, but
one could imagine overloading &[char] etc.)
These examples don't look that inspiring, but these changes have sent
me on a lightning tour of the whole code base, and it seems that there
are many instances where using iterators more extensively will be
easily possibly (if anyone's interested in experimenting, grepping for
.iter() or .rev_iter(), or even .map() in librustc would be a starting
point).
# Method-isation
We've been converting a large number of freestanding functions in str
to methods (and a few in vec too), and *deleting* the original
functions. I know Rust is not quite aiming for backward-compatibility
yet, but this might be a bit too much... it gives non-obvious name
resolution errors. Since we don't have #[deprecated] yet[deprecated],
I'm (slightly) willing to add them back in with #[doc(hidden)], but
forcing the issue by an outright removal would be extremely nice to
clean up these two huge modules.
In any case, most of them have been just copied into the appropriate
trait, and all of these traits are in the prelude, so an error about
{str,vec}::foo(bar, ...) can normally be fixed via bar.foo(...).
Anyway, I'm taking the approach that adding these modules are old and
need to be cleaned out, and adding things back into the modules is
easy, but deleting things is hard (since, unsurprisingly, the
functions get used through the compiler) and boring, but should be
done as soon as possible. So far, pending that pull request, we've
reduced the length of str by ~25% and vec about ~5% (I've been mainly
focusing on str, Daniel has done bits and pieces on vec), with more
possible.
Huon Wilson
[iterators]:
https://mail.mozilla.org/pipermail/rust-dev/2013-June/004364.html
[use]: https://github.com/mozilla/rust/issues/5898
[for]: https://github.com/mozilla/rust/issues/6997
[deprecated]: https://github.com/mozilla/rust/issues/723
[pending pull]: https://github.com/mozilla/rust/pull/7032 r? :)
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
