"downstream crates may implement trait for type" for both trait and type private to this crate

[tisonkun]

$ rustc --version
rustc 1.83.0-nightly (363ae4188 2024-09-24)

use std::cmp::Ordering;
use compare::Compare;
use num_cmp::NumCmp;

trait PartialCompare<L: ?Sized, R: ?Sized = L> {
    fn compare(&self, l: &L, r: &R) -> Option<Ordering>;
}

impl<L, R, C: Compare<L, R>> PartialCompare<L, R> for C {
    fn compare(&self, l: &L, r: &R) -> Option<Ordering> {
        Some(self.compare(l, r))
    }
}

#[derive(Default, Debug, Clone, Copy)]
struct NumCompare;

impl<L, R> PartialCompare<L, R> for NumCompare
where
    L: NumCmp<R> + Copy,
    R: Copy,
{
    fn compare(&self, l: &L, r: &R) -> Option<Ordering> {
        NumCmp::num_cmp(*l, *r)
    }
}


fn main() {}

With dependencies:

num-cmp = "0.1.0"
compare = "0.1.0"

Failed to compile:

error[E0119]: conflicting implementations of trait `PartialCompare<_, _>` for type `NumCompare`
  --> src/main.rs:18:1
   |
9  |   impl<L, R, C: Compare<L, R>> PartialCompare<L, R> for C {
   |   ------------------------------------------------------- first implementation here
...
18 | / impl<L, R> PartialCompare<L, R> for NumCompare
19 | | where
20 | |     L: NumCmp<R> + Copy,
21 | |     R: Copy,
   | |____________^ conflicting implementation for `NumCompare`
   |
   = note: downstream crates may implement trait `compare::Compare<_, _>` for type `NumCompare`

Since both PartialCompare and NumCompare are defined in this crate, the error message seems incorrect. Not sure it's a bug or an error messaging inaccurate.

[SkiFire13]

The compare crate may add impl<T, L, R> Compare<L, R> for T, which would implement Compare<L, R> for your NumCompare and thus conflict with your implementation.

[tisonkun]

@SkiFire13 When I manually expand the implement to:

impl PartialCompare<i64, u64> for NumericCompare {
    fn compare(&self, l: &i64, r: &u64) -> Option<Ordering> {
        NumCmp::num_cmp(*l, *r)
    }
}

impl PartialCompare<u64, i64> for NumericCompare {
    fn compare(&self, l: &u64, r: &i64) -> Option<Ordering> {
        NumCmp::num_cmp(*l, *r)
    }
}

It works. But in your explanation as impl<T, L, R> Compare<L, R> for T may be added this should "conflict" also.

[cuviper]

The compare crate may add impl<T, L, R> Compare<L, R> for T,

That would be a breaking change in the compare crate, since concrete types downstream may already implement it.

[tisonkun]

@cuviper Yeah. I think if so there should be a circular dependencies and the compiler will reject to compile it.

So my original code something Rust compiler is supposed to compile?

[cuviper]

So my original code something Rust compiler is supposed to compile?

AFAIK, coherence has no consideration of the type/trait being private this crate, even when there's no possible downstream, like your example as a main binary. That is, it's not expected to work, but perhaps as an enhancement it could?