nightly rustc breaks stable code for some type inferences

[bombless]

use std::ops::Add;
trait Zero: Add<Self, Output=Self> {
    fn zero()->Self;
}

impl Zero for i32 {
    fn zero()->i32 {
        0
    }
}

fn main() {
    let mut x = Vec::<i32>::new();
    x.extend(vec![Zero::zero()].into_iter())
}

nightly (breaking) : http://is.gd/5Pl8DA
stable (compiles) : http://is.gd/ZLTyOv

[alexcrichton]

triage: I-nominated

[bluss]

There's a tag on PR #25989 already too.

[nikomatsakis]

triage: P-high

[nikomatsakis]

Gave P-high because this is a regression.

[bluss]

It's deliberate, due to new Extend impls in libstd, on for example Vec.

[jroesch]

@bluss I'm out of the std loop could you elaborate?

[bluss]

Sure, Vec<T> and other collections used to implement only Extend<T> so x.extend(vec![Zero::zero()].into_iter()) would infer the type for the Zero uniquely, from the type of x.

Now, Vec<T> implements both Extend<T> and Extend<&T> where T: Copy, so it is ambiguous which type the Zero call should produce.

I said it was deliberate because we knew that this issue would exist, a new trait impl would make some code ambiguous. It is called minor change (but breaking change) in the rust policy on stability, and hence permitted. (RFC: Policy on semver and API evolution)

One convenient workaround is to just use the explict form: i32::zero() (hm that's silly, but I suspect the original case has a type parameter). With a type parameter it can be written T::zero().

[nikomatsakis]

I'm going to close this issue, since we've decided that the breakage due to extend is acceptable.