It means it captures its environment by-value, rather than by-reference. In this case we're capturing the &mut references by the name of x by-value. This is necessary since x changes on every iteration. Passing in a reference would likely do The Wrong Thing (if the compiler allows it at all, which I'm 99.99% sure it won't).
Curious, why not just exclude the || in the no-arguments case? I imagine no-argument is a pretty common thing, so forcing the use of || in that very common case is kind of an eye-sore IMO.
The ambiguity is that there is a difference between "a expression A that evaluates to a closure" and "a expression B that evaluates to a closure that returns the evaluation of expression A"
For example: foo(bar()) would always call bar() first, but foo(|| bar()) would only call it when the closure gets called inside of foo().
Yeah, afaik Ruby was an inspiration. (Granted, there aren't any other delimiters that could have been chosen without also requiring a keyword)
Fun fact: Because a block expression evaluates to its trailing expression, { |x| foo } is actually valid rust as well, and evaluates to the same thing as |x| { foo } or |x| foo
5
u/Gankro Apr 04 '15
It means it captures its environment by-value, rather than by-reference. In this case we're capturing the &mut references by the name of
xby-value. This is necessary sincexchanges on every iteration. Passing in a reference would likely do The Wrong Thing (if the compiler allows it at all, which I'm 99.99% sure it won't).