Why is “&&” being used in closure arguments?

by

a is of type [i32; 3]; an array of three i32s.
[i32; 3] does not implement an iter method, but it does dereference into &[i32].
&[i32] implements an iter method which produces an iterator.
This iterator implements Iterator<Item=&i32>.

It uses &i32 rather than i32 because the iterator has to work on arrays of any type, and not all types can be safely copied. So rather than restrict itself to copyable types, it iterates over the elements by reference rather than by value.

find is a method defined for all Iterators. It lets you look at each element and return the one that matches the predicate. Problem: if the iterator produces non-copyable values, then passing the value into the predicate would make it impossible to return it from find. The value cannot be re-generated, since iterators are not (in general) rewindable or restartable. Thus, find has to pass the element to the predicate by-reference rather than by-value.

So, if you have an iterator that implements Iterator<Item=T>, then Iterator::find requires a predicate that takes a &T and returns a bool. [i32]::iter produces an iterator that implements Iterator<Item=&i32>. Thus, Iterator::find called on an array iterator requires a predicate that takes a &&i32. That is, it passes the predicate a pointer to a pointer to the element in question.

So if you were to write a.iter().find(|x| ..), the type of x would be &&i32. This cannot be directly compared to the literal i32 value 2. There are several ways of fixing this. One is to explicitly dereference x: a.iter().find(|x| **x == 2). The other is to use pattern matching to destructure the double reference: a.iter().find(|&&x| x == 2). These two approaches are, in this case, doing exactly the same thing. [1]

As for why Some(&2) is used: because a.iter() is an iterator over &i32, not an iterator of i32. If you look at the documentation for Iterator::find, you’ll see that for Iterator<Item=T>, it returns an Option<T>. Hence, in this case, it returns an Option<&i32>, so that’s what you need to compare it against.

[1]: The differences only matter when you’re talking about non-Copy types. For example, |&&x| .. wouldn’t work on a &&String, because you’d have to be able to move the String out from behind the reference, and that’s not allowed. However, |x| **x .. would work, because that is just reaching inside the reference without moving anything.

More Related Contents:

  1. Why is it discouraged to accept a reference to a String (&String), Vec (&Vec), or Box (&Box) as a function argument?
  2. Is there any way to return a reference to a variable created in a function?
  3. Why can I return a reference to a local literal but not a variable?
  4. Cannot move out of borrowed content / cannot move out of behind a shared reference
  5. Why are explicit lifetimes needed in Rust?
  6. Cannot borrow as mutable because it is also borrowed as immutable
  7. How do I implement the Add trait for a reference to a struct?
  8. Cannot move out of borrowed content when trying to transfer ownership
  9. How to avoid writing duplicate accessor functions for mutable and immutable references in Rust?
  10. Iterator returning items by reference, lifetime issue
  11. Why does pattern matching on &Option yield something of type Some(&T)?
  12. What is the purpose of `&` before the loop variable?
  13. When should I not implement a trait for references to implementors of that trait?
  14. What is an idiomatic way to collect an iterator of &T into a collection of Ts?
  15. How to abstract over a reference to a value or a value itself?
  16. Rust lifetime error expected concrete lifetime but found bound lifetime
  17. Why can’t I store a value and a reference to that value in the same struct?
  18. How can I pass a reference to a stack variable to a thread?
  19. What are Rust’s exact auto-dereferencing rules?
  20. Cannot obtain a mutable reference when iterating a recursive structure: cannot borrow as mutable more than once at a time
  21. What’s the difference between placing “mut” before a variable name and after the “:”?
  22. Why does linking lifetimes matter only with mutable references?
  23. Why is the return type of Deref::deref itself a reference?
  24. Convert Vec into a slice of &str in Rust?
  25. What lifetimes do I use to create Rust structs that reference each other cyclically?
  26. How can I mutate other elements of a HashMap when using the entry pattern?
  27. How to query mongodb with DBRef
  28. Finding all references of a variable or a method in Xcode4
  29. How can I conditionally provide a default reference without performing unnecessary computation when it isn’t used?
  30. Pass by reference problem with PHP 5.3.1 [duplicate]

Leave a Comment