¿Cuál es la diferencia entre iter e into_iter?

Estoy haciendo el tutorial Rust by Example que tiene este fragmento de código:

// Vec example
let vec1 = vec![1, 2, 3];
let vec2 = vec![4, 5, 6];

// `iter()` for vecs yields `&i32`. Destructure to `i32`.
println!("2 in vec1: {}", vec1.iter()     .any(|&x| x == 2));
// `into_iter()` for vecs yields `i32`. No destructuring required.
println!("2 in vec2: {}", vec2.into_iter().any(| x| x == 2));

// Array example
let array1 = [1, 2, 3];
let array2 = [4, 5, 6];

// `iter()` for arrays yields `&i32`.
println!("2 in array1: {}", array1.iter()     .any(|&x| x == 2));
// `into_iter()` for arrays unusually yields `&i32`.
println!("2 in array2: {}", array2.into_iter().any(|&x| x == 2));

Estoy completamente confundido: para un Veciterador devuelto de las iterreferencias de rendimiento y el iterador devuelto de los into_itervalores de rendimiento, pero para una matriz, estos iteradores son idénticos.

¿Cuál es el caso de uso / API para estos dos métodos?

TL; DR:

• El iterador devuelto por into_iterpuede producir cualquiera de T, &To &mut T, dependiendo del contexto.
• El iterador devuelto por iterrendirá &T, por convención.
• El iterador devuelto por iter_mutrendirá &mut T, por convención.

La primera pregunta es: "¿Qué es into_iter?"

into_iterproviene del IntoIteratorrasgo :

pub trait IntoIterator 
where
    <Self::IntoIter as Iterator>::Item == Self::Item, 
{
    type Item;
    type IntoIter: Iterator;
    fn into_iter(self) -> Self::IntoIter;
}

Implementa este rasgo cuando desea especificar cómo se convertirá un tipo particular en un iterador. En particular, si un tipo lo implementa IntoIterator, puede usarse en un forbucle.

Por ejemplo, Vecimplementa IntoIterator... ¡tres veces!

impl<T> IntoIterator for Vec<T>
impl<'a, T> IntoIterator for &'a Vec<T>
impl<'a, T> IntoIterator for &'a mut Vec<T>

Cada variante es ligeramente diferente.

Este consume el Vecy su iterador produce valores ( Tdirectamente):

impl<T> IntoIterator for Vec<T> {
    type Item = T;
    type IntoIter = IntoIter<T>;

    fn into_iter(mut self) -> IntoIter<T> { /* ... */ }
}

Los otros dos toman el vector por referencia (no se deje engañar por la firma de into_iter(self)porque selfes una referencia en ambos casos) y sus iteradores producirán referencias a los elementos en su interior Vec.

Este produce referencias inmutables :

impl<'a, T> IntoIterator for &'a Vec<T> {
    type Item = &'a T;
    type IntoIter = slice::Iter<'a, T>;

    fn into_iter(self) -> slice::Iter<'a, T> { /* ... */ }
}

Si bien este produce referencias mutables :

impl<'a, T> IntoIterator for &'a mut Vec<T> {
    type Item = &'a mut T;
    type IntoIter = slice::IterMut<'a, T>;

    fn into_iter(self) -> slice::IterMut<'a, T> { /* ... */ }
}

Entonces:

¿Cuál es la diferencia entre itery into_iter?

into_iteres un método genérico para obtener un iterador, si este iterador produce valores, referencias inmutables o referencias mutables depende del contexto y a veces puede ser sorprendente.

itery iter_mutson métodos ad-hoc. Su tipo de retorno es, por lo tanto, independiente del contexto, y convencionalmente serán iteradores que producirán referencias inmutables y referencias mutables, respectivamente.

El autor de la publicación Rust by Example ilustra la sorpresa que viene de la dependencia del contexto (es decir, el tipo) al que into_iterse llama, y ​​también agrava el problema al usar el hecho de que:

1. IntoIteratorno está implementado para [T; N], solo para &[T; N]y&mut [T; N]
2. Cuando un método no se implementa para un valor, se busca automáticamente referencias a ese valor

lo cual es muy sorprendente into_iterya que todos los tipos (excepto [T; N]) lo implementan para las 3 variaciones (valor y referencias). No es posible que la matriz implemente un iterador que arroje valores porque no puede "reducir" para renunciar a sus elementos.

En cuanto a por qué se implementan las matrices IntoIterator(de una manera tan sorprendente): es para hacer posible iterar sobre las referencias a ellas en forbucles.

Yo (un novato de Rust) vine de Google buscando una respuesta simple que no fue proporcionada por las otras respuestas. Aquí está esa respuesta simple:

• iter() itera sobre los elementos por referencia
• into_iter() itera sobre los elementos, moviéndolos al nuevo alcance
• iter_mut() itera sobre los elementos, dando una referencia mutable a cada elemento

Así que for x in my_vec { ... }es esencialmente equivalente a my_vec.into_iter().for_each(|x| ... )- tanto movelos elementos de my_vecen el ...ámbito de aplicación.

Si solo necesita "mirar" los datos, use iter, si necesita editarlos / mutarlos, use iter_mut, y si necesita darle un nuevo propietario, use into_iter.

Esto fue útil: http://hermanradtke.com/2015/06/22/effectively-using-iterators-in-rust.html

Hacer de este un wiki de la comunidad para que un profesional de Rust pueda editar esta respuesta si cometí algún error

.into_iter()no se implementa para una matriz en sí, sino solo &[]. Comparar:

impl<'a, T> IntoIterator for &'a [T]
    type Item = &'a T

con

impl<T> IntoIterator for Vec<T>
    type Item = T

Como IntoIteratorse define solo en &[T], el segmento en sí no se puede descartar de la misma manera que Veccuando usa los valores. (los valores no se pueden mover)

Ahora, por qué ese es el caso es un problema diferente, y me gustaría aprender yo mismo. Especulando: la matriz son los datos en sí, el segmento es solo una vista. En la práctica, no puede mover la matriz como valor a otra función, simplemente pasar una vista de ella, por lo que tampoco puede consumirla allí.

Creo que hay algo que aclarar un poco más. Los tipos de colección, como Vec<T>y VecDeque<T>, tienen un into_itermétodo que rinde Tporque se implementan IntoIterator<Item=T>. No hay nada que nos detenga para crear un tipo Foo<T>si se repite, no dará Tsino otro tipo U. Es decir, Foo<T>implementos IntoIterator<Item=U>.

De hecho, hay algunos ejemplos en std: &Path implementos IntoIterator<Item=&OsStr> e &UnixListener implementos IntoIterator<Item=Result<UnixStream>> .

La diferencia entre into_iteryiter

Volviendo a la pregunta original sobre la diferencia entre into_itery iter. Similar a lo que otros han señalado, la diferencia es que into_iteres un método requerido IntoIteratorque puede producir cualquier tipo especificado en IntoIterator::Item. Típicamente, si un tipo se implementa IntoIterator<Item=I>, por convención también tiene dos métodos ad-hoc: itery iter_mutque rinden &Iy &mut I, respectivamente.

Lo que implica es que podemos crear una función que recibe un tipo que tiene un into_itermétodo (es decir, es iterable) mediante el uso de un límite de rasgo:

fn process_iterable<I: IntoIterator>(iterable: I) {
    for item in iterable {
        // ...
    }
}

Sin embargo, no podemos ^* usar un rasgo obligado a requerir que un tipo tenga un itermétodo o iter_mutmétodo, porque son solo convenciones. Podemos decir que into_iteres más ampliamente utilizable que itero iter_mut.

Alternativas a iteryiter_mut

Otro iteraspecto interesante para observar es que no es la única forma de obtener un iterador que rinda &T. Por convención (nuevamente), los tipos de colección SomeCollection<T>en los stdque tienen itermétodo también tienen &SomeCollection<T>implementados sus tipos de referencia inmutables IntoIterator<Item=&T>. Por ejemplo, &Vec<T> implementa IntoIterator<Item=&T> , por lo que nos permite iterar sobre &Vec<T>:

let v = vec![1, 2];

// Below is equivalent to: `for item in v.iter() {`
for item in &v {
    println!("{}", item);
}

Si v.iter()es equivalente a &vque ambos implementos IntoIterator<Item=&T>, ¿por qué Rust proporciona ambos? Es para la ergonomía. En forbucles, es un poco más conciso de usar &vque v.iter(); pero en otros casos, v.iter()es mucho más claro que (&v).into_iter():

let v = vec![1, 2];

let a: Vec<i32> = v.iter().map(|x| x * x).collect();
// Although above and below are equivalent, above is a lot clearer than below.
let b: Vec<i32> = (&v).into_iter().map(|x| x * x).collect();

Del mismo modo, en forbucles, v.iter_mut()se puede reemplazar con &mut v:

let mut v = vec![1, 2];

// Below is equivalent to: `for item in v.iter_mut() {`
for item in &mut v {
    *item *= 2;
}

Cuándo proporcionar (implementar) into_itery itermétodos para un tipo

Si el tipo solo tiene una "forma" para iterar, deberíamos implementar ambas. Sin embargo, si hay dos formas o más de que se puede repetir, deberíamos proporcionar un método ad-hoc para cada forma.

Por ejemplo, Stringno proporciona into_iterni iterporque hay dos formas de iterarlo: iterar su representación en bytes o iterar su representación en caracteres. En cambio, proporciona dos métodos: bytespara iterar los bytes y charspara iterar los caracteres, como alternativas al itermétodo.

^* Bueno, técnicamente podemos hacerlo creando un rasgo. Pero entonces necesitamos implese rasgo para cada tipo que queremos usar. Mientras tanto, muchos tipos stdya se implementan IntoIterator.