Types should be inferrable across bit boolean operators

[tgross35]

I have not been able to find an issue documenting this (perhaps I haven't been looking for the right thing), but it is a bit surprising that type inference doesn't seem to carry across boolean operators well. Example code:

fn main() {
    let x: u8 = 100;              // setup
    let y: u32 = x.into();        // example
    let z: u32 = 1u32 | x;           // option 1
    let z: u32 = 1u32 | x.into();    // option 2
    let z: u32 = 1u32 | (x as u32);  // working solution

    println!("{y}");
}

With only option 1 enabled, we get the following:

error[[E0308]](https://doc.rust-lang.org/stable/error-index.html#E0308): mismatched types
 --> src/main.rs:6:25
  |
6 |     let z: u32 = 1u32 | x;           // option 1
  |                         ^ expected `u32`, found `u8`

So, the compiler is aware of the expected type, seems like the perfect case for into rather than a cast. However, when switching to option 2:

error[[E0284]](https://doc.rust-lang.org/stable/error-index.html#E0284): type annotations needed
 --> src/main.rs:7:27
  |
7 |     let z: u32 = 1u32 | x.into();    // option 2
  |                       -   ^^^^
  |                       |
  |                       type must be known at this point

it is unable to infer the type. Which is a bit unexpected, because true booleans operators like if true && 1u8.into() work enough that it knows there is no From<u8> for bool.

Maybe there is some restriction for why this couldn't be implemented for all types, but it would be quite handy to have for integers.

[compiler-errors]

Just noting that this is probably going to be impossible.

The problem here essentially boils down to the fact that bitwise operators are implementable by the user, whereas short-circuiting operators are not.

Since there's more than one implementation of BitOr for u32 provided by the standard library -- specifically, u32 implements BitOr<NonZeroU32>, BitOr<&u32> and BitOr<u32>, we can't use the existence of a single implementation to infer what the right hand side of the operator should be¹.

So we'd need to add a custom rule here to prefer built-in types on ambiguity or something, which seems like an additional inference wrinkle that I personally wouldn't want to support here, given that you can fix the error by providing extra type annotations.

Footnotes

1. Though even this strategy is somewhat fragile, since if anywhere in the crate graph there's another implementation of BitOr<MyType> for u32 added, then that inference would break. This happens annoyingly due to the existence of only a single Add<_> for String implementation in the standard library. ↩

[tgross35]

I didn't even realize that none of the math ops work let z: u32 = 1u32 + x.into(), intersting.

Would it be possible or sound if a rule preferred to use make the lhs and rhs identical if the type is Copy? A second choice could be &T if the type isn't copy (or more generally, anything with Deref). It seems that would resolve this issue for numeric primitives, probably just about the only relevant use case.