Generic causes other trait implementations of concrete type to be ignored.

[daniel-wong-dfinity-org]

I tried this code:

use rust_decimal::{
    // The important thing about this type is that you can do Decimal::from(1).
    Decimal,
};

fn this_is_not_generic() {
    Decimal::from(1); // This is accepted.
}

fn this_is_indeed_generic<Inp>(inp: Inp)
where
    // All I am saying here is that you can convert from Inp to Decimal.
    // I am NOT saying that ONLY Inp can be converted to Decimal.
    Decimal: From<Inp> 
{
    Decimal::from(1); // This is rejected. WTF?
}

I expected to see this happen: My code is accepted.

Instead, this happened: My code is rejected. More precisely,

error[E0308]: mismatched types
  --> src/lib.rs:16:19
   |
10 | fn this_is_indeed_generic<Inp>(inp: Inp)
   |                           --- expected this type parameter
...
16 |     Decimal::from(1); // This is rejected. WTF?
   |     ------------- ^ expected type parameter `Inp`, found integer
   |     |
   |     arguments to this function are incorrect
   |
   = note: expected type parameter `Inp`
                        found type `{integer}`
note: associated function defined here
  --> /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/convert/mod.rs:585:8

For more information about this error, try `rustc --explain E0308`.
error: could not compile `repro` (lib) due to 1 previous error

Meta

$ rustc --version --verbose
rustc 1.80.0 (051478957 2024-07-21)
binary: rustc
commit-hash: 051478957371ee0084a7c0913941d2a8c4757bb9
commit-date: 2024-07-21
host: aarch64-apple-darwin
release: 1.80.0
LLVM version: 18.1.7

Behavior on +nightly:

error[E0308]: mismatched types
  --> src/lib.rs:16:19
   |
10 | fn this_is_indeed_generic<Inp>(inp: Inp)
   |                           --- expected this type parameter
...
16 |     Decimal::from(1); // This is rejected. WTF?
   |     ------------- ^ expected type parameter `Inp`, found integer
   |     |
   |     arguments to this function are incorrect
   |
   = note: expected type parameter `Inp`
                        found type `{integer}`
note: associated function defined here
  --> /rustc/52fd9983996d9fcfb719749838336be66dee68f9/library/core/src/convert/mod.rs:585:8

For more information about this error, try `rustc --explain E0308`.
error: could not compile `repro` (lib) due to 1 previous error

[QTi1]

I'm having an issue that feels related. The following compiles:

use std::ops::Add;

fn add_f64_f64_U<U>(a: f64, b: f64, c: U) -> U
where
    f64: Add<U, Output = U>,
    f64: Add<f64, Output = f64>,
{
    a + b + c
}

But swapping the order of trait bounds does not compile:

use std::ops::Add;

fn add_f64_f64_U<U>(a: f64, b: f64, c: U) -> U
where
    f64: Add<f64, Output = f64>,
    f64: Add<U, Output = U>,
{
    a + b + c
}

That ordering gets this error:

error[E0308]: mismatched types
 --> src/lib.rs:8:9
  |
3 | fn add_f64_f64_U<U>(a: f64, b: f64, c: U) -> U
  |                  - expected this type parameter
...
8 |     a + b + c
  |         ^ expected type parameter `U`, found `f64`
  |
  = note: expected type parameter `U`
                       found type `f64`

Also, adding a concrete type that can be added to f64 causes it to not compile:

use std::ops::Add;

fn add_f64_f64_U<U>(a: f64, b: f64, c: U) -> U
where
    f64: Add<U, Output = U>,
    f64: Add<f64, Output = f64>,
{
    a + b + c
}

struct F64Wrapper {
    inner: f64,
}
impl Add<F64Wrapper> for f64 {
    type Output = F64Wrapper;
    fn add(self, rhs: F64Wrapper) -> F64Wrapper {
        F64Wrapper {
            inner: self + rhs.inner,
        }
    }
}

with the same error. There was some discussion of this on Reddit at https://www.reddit.com/r/learnrust/comments/1gghbd8/trouble_with_multiple_add_trait_bounds/.
Here's my version:

$ rustc --version --verbose
rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-unknown-linux-gnu
release: 1.82.0
LLVM version: 19.1.1

[workingjubilee]

assigning it to the usual suspects, since I suspect they will be most-capable of commenting on it.

[adwinwhite]

Looks like #24066.

[lcnr]

Yeah, closing as duplicate of #24066

This behavior is definitely suboptimal and we should be able to change it with the new solver. At least in future editions