Compiling foreach v0.2.0 (file:///Users/jdm/src/iter_foreach)
error: use of unstable library feature 'iterator_for_each' (see issue #42986)
--> tests/basic.rs:10:10
|
10 | iter.for_each(|item, iter| {
| ^^^^^^^^
|
= help: add #![feature(iterator_for_each)] to the crate attributes to enable
error[E0593]: closure takes 2 arguments but 1 argument is required
--> tests/basic.rs:10:10
|
10 | iter.for_each(|item, iter| {
| __________^^^^^^^^_-
| | |
| | expected closure that takes 1 argument
11 | | assert_eq!(item, i * 2);
12 | | i += 1;
13 | | let _ = iter.next();
14 | | });
| |___________________- takes 2 arguments
error: aborting due to 2 previous errors
error: Could not compile `foreach`.
warning: build failed, waiting for other jobs to finish...
error: build failed
cc @jaje
It appears that a new unstable feature was implemented that conflicts with the for_each crate. rustc interprets the use of Iterator::for_each as attempting to use the unstable feature instead of the trait method defined by the for_each crate.
I think this is expected breakage, since you could use UFC syntax to call the method you mean. Otherwise we could never add new methods to any type or trait.
I'm surprised that it just assumes the code wanted Iterator::for_each, rather than reporting an ambiguity between that and ForEach::for_each. I thought only inherent methods took precedence like that. Is it because Iterator is in the prelude?
If iter is a generic T: Iterator or an &mut Iterator trait object, Iterator::for_each is treated somewhat inherently I believe. Seems like something's busted in the check if iter is a concrete type though.
In that test iter is a concrete type, a range.
The libs team decided to hold off on evaluating what to do here until we have a crater report to see what the brekage is.
A crater report for beta happened, and I don't believe we saw any other regressions related to this, so I'm going to close this now.
Most helpful comment
I'm surprised that it just assumes the code wanted
Iterator::for_each, rather than reporting an ambiguity between that andForEach::for_each. I thought only inherent methods took precedence like that. Is it becauseIteratoris in the prelude?