Type inference regression on beta using as _

[bstrie]

Spotted by @gankro :

fn main() {
    let mut x: u64 = 0;
    let y: u32 = 0;
    x += y as _;   // Compiles on stable, fails on beta/nightly
}

[ollie27]

I believe this is expected breakage from #44287.

[jrmuizel]

It would be valuable to have a list breaking changes that's updated whenever something breaking lands.

[pietroalbini]

This also happens when using methods like parse:

fn main() {
    let mut var = 0;
    let other = "10".parse().unwrap();  // Fails on beta/nightly
    var += other;
}

Edit: and also this, which is a bit annoying:

fn main() {
    let mut result = 0;
    result += "10".parse().unwrap();  // Fails on beta/nightly
    println!("{}", result);
}

[Mark-Simulacrum]

Also occurs in average-0.6.2 cc @vks

[Mark-Simulacrum]

As well as:
minions-0.2.8 log cc @dbeck
netlink-rs-0.0.3 cc @crhino
odds-0.2.25 cc @bluss
pbr-demo log cc @samsartor

[Mark-Simulacrum]

And also whiteread-0.4.3 cc @krdln

[vks]

Thanks for the heads-up, this was fixed in average-0.6.3, or vks/average@b8d31c8. As suggested by @ollie27, this was an expected breakage due to #44287.

[egilburg]

Should as be at all needed in the above example? if x is u64 and y is u32, it seems the only choice is to upcast y to x, it's not something that's ambiguous or could be hand-coded any better. Could the compiler detect that and make just x += y compile without manual upcast, in the same spirit as making x += &y work without manual deref?

Other cases may be more ambiguous (e.g. adding a u64 to a u32) since the u64 value may not fit in the u32, but adding a u32 to a u64 seems to be lossless (sans integer overflow which is already existing issue on any integer math even of the same type). And even in the u32 += u64 case, it already works with the as u32 example (or as _ on Stable) when the u64 had a value too large for u32, silently losing the non-fitting data.

---

Also, just because the stability guarantees technically allow these types of breaking changes, doesn't necessarily mean it's a great idea to do so. It seems a lot of valid code is broken, and fixing it requires extra verbosity compared to what the compiler was previously able to resolve, which goes against the spirit of the ergonomics initiative.

[lilianmoraru]

Yep, this looks really bad:

result += "10".parse().unwrap();  // Fails on beta/nightly
println!("{}", result);

[Mark-Simulacrum]

@rust-lang/libs: Closing this as we can't revert now as this has leaked onto stable. Ideally we'd probably have type defaults or something to avoid this in the future.