As per [RFC #235][rfc], you can now do:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0235-collections-conventions.md#intoiterator-and-iterable
``` rust
let mut v = vec![1];
// iterate over immutable references
for x in &v {
assert_eq!(x, &1);
}
// iterate over mutable references
for x in &mut v {
assert_eq!(x, &mut 1);
}
// iterate over values, this consumes `v`
for x in v {
assert_eq!(x, 1);
}
```
[breaking-change]s
For loops now "consume" (move) the iterator, this breaks iterating over mutable references to iterators, and also breaks multiple iterations over the same iterator:
``` rust
fn foo(mut it: &mut Iter) { // `Iter` implements `Iterator`
for x in it { .. } //~ error: `&mut Iter` doesn't implement Iterator
}
fn bar() {
for x in it { .. } //~ note: `it` moved here
for x in it { .. } //~ error: `it` has been moved
}
```
Both cases can be fixed using the `by_ref()` adapter to create an iterator from the mutable reference:
``` rust
fn foo(mut it: &mut Iter) {
for x in it.by_ref() { .. }
}
fn bar() {
for x in it.by_ref() { .. }
for x in it { .. }
}
```
This PR also makes iterator non-implicitly copyable, as this was source of subtle bugs in the libraries. You can still use `clone()` to explictly copy the iterator.
Finally, since the for loops are implemented in the frontend and use global paths to `IntoIterator`, `Iterator` and `Option` variants, users of the `core` crate will have to use add an `std` module to the root of their crate to be able to use for loops:
``` rust
#![no_std]
extern crate core;
fn main() {
for x in 0..10 {}
}
#[doc(hidden)]
mod std {
// these imports are needed to use for-loops
pub use core::iter;
pub use core::option;
}
```
---
r? @nikomatsakis @aturon
cc #18424closes#18045
Coercions will now attempt to autoderef as needed before reborrowing.
This includes overloaded `Deref`, e.g. `&Rc<T>` coerces to `&T`, and
`DerefMut`, e.g. `&mut Vec<T>` coerces to `&mut [T]` (in addition to `&[T]`).
Closes#21432.
trans: When coercing to `Box<Trait>` or `Box<[T]>`, leave datum in it's original L-/R-value state.
This fixes a subtle issue where temporaries were being allocated (but not necessarily initialized) to the (parent) terminating scope of a match expression; in particular, the code to zero out the temporary emitted by `datum.store_to` is only attached to the particular match-arm for that temporary, but when going down other arms of the match expression, the temporary may falsely appear to have been initialized, depending on what the stack held at that location, and thus may have its destructor erroneously run at the end of the terminating scope.
FIx#20055.
(There may be a latent bug still remaining in `fn into_fat_ptr`, but I am so annoyed by the test/run-pass/coerce_match.rs failures that I want to land this now.)
It was considered to be impossible but actually it can
happen for nested closures. Also, because there must
be nested closures when this happens, we can use more
targeted help message.
Closes#21390Closes#21600
Note: Do not merge until we get a newer snapshot that includes #21374
There was some type inference fallout (see 4th commit) because type inference with `a..b` is not as good as with `range(a, b)` (see #21672).
r? @alexcrichton
