A big issue is Rust collections can (and often want to) provide multiple iterators depending whether the yielded values should be references, mutable references, … Most collections provide both iter() and iter_mut() for instance, and these are not *views* (in e.g. the Python sense), they don't iterate on a subset of the collection, instead they provide a different level of access to the current iteration value.
There have been suggestions about an Iterable trait, there is an open RFC (https://github.com/rust-lang/rfcs/pull/17) and IIRC the collections reform (https://github.com/rust-lang/rfcs/pull/235) contains a subset of it, but so far the explicit iterator has not been a huge wart or issue. It can also be changed in a completely backwards-compatible manner so it can be tackled post-1.0. On 2015-01-01, at 11:49 , Pim Schellart <[email protected]> wrote: > Dear Rust developers, > > I have just started using rust so this is obviously a stupid question but I > was wondering why .iter() is needed when looping over the elements of an > array? In the following example: > > let a = [1i, 2i, 3i]; > > for e in a.iter() { > println!("{}", e); > } > > why can’t one simply write: > > let a = [1i, 2i, 3i]; > > for e in a { > println!("{}", e); > } > > and have the compiler figure out that ‘a’ has ‘.iter()’ and use it? The form > without .iter() just feels more natural to me in this case. > Please feel free to tell me to RTFM or ask this question elsewhere. > > Regards, > > Pim > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
