Stabilizing Iterator::intersperse breaks a large number of crates

[Mark-Simulacrum]

The 1.56 crater run shows that there are at least 59 root crates (or repositories) broken by this change, and 260 crates.io crates along with 278 github repositories which depend on those.

See https://crater-reports.s3.amazonaws.com/beta-1.56-2/index.html > "regressed: root results" > E0034 for the root crates.

cc some threads with partial discussion:

• https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/possible.20semi-breaking.20change.20in.20next.20release
• Recent PRs break lots of nightly builds #88878

Nominating for T-libs-api discussion as the FCP on #79524 seems to have been made without commentary about the expected level of breakage, so I suspect it was not discussed.

[the8472]

Given #48552, rust-itertools/itertools#576 might solve this assuming it gets merged and released before 1.56 reaches stable.

Edit, wait... was the check for deprecated candidates in #48552 (comment) implemented? Doesn't look like it.

[yaahc]

During yesterday's libs-api team meeting we discussed how we can stabilize intersperse without causing large amounts of breakage across the ecosystem. The plan we arrived upon is to first revert the stabilization and then plan on stabilizing the feature in a future release, @Mark-Simulacrum suggested 1.65.

Whenever we end up stabilizing it we need to have a plan for how we will avoid these same breakages. Suggestions so far include using build scripts or #[cfg(accessible(...)] in itertools to detect the presence of intersperse in std and disable Itertools::intersperse when there would be a conflict.

In a previous meeting we also discussed more long term solutions we could implement to avoid ambiguity breakages caused by introducing new methods like this. Suggestions in that meeting included:

• encoding the released std version in crates published to crates.io when uploading and ignore methods introduced in newer releases when building that published version
• annotating the edition in which new methods were added to de-prioritize them when ambiguity arises and emit a warning which indicates there is an ambiguity and that it will be promoted to a hard error in future editions.

[jswrenn]

Whenever we end up stabilizing it we need to have a plan for how we will avoid these same breakages.

I believe the accepted supertrait_item_shadowing RFC might provide a long-term solution to this kind of breakage.