Deranged 0.4.1 breaks build of other crates (`PartialEq` with empty slices)

[chifflier]

Hi,

After a cargo update from 0.4.0 to 0.4.1, building unit tests breaks in unrelated parts of my crate (asn1-rs) due to a conflicting implementation of PartialEq. Building with 0.4.0 works fine

I know this has already been reported, however I think this is not a duplicate:

• I have updated all dependencies using a global cargo update (including time and deranged), problem is still here
• cargo outdated shows to crate to upgrade
• this seems to happen only with empty slices
• this happens in code not importing time nor deranged

I tried to pin the problem to a minimal test case
The errors are related to comparisons of empty &[u8] (non-empty comparison work). For ex, the following fails:

fn build_failure() {
    let b1 = &[0_u8, 1];
    assert_eq!(b1, &[]);
}

Edit: the minimal crate I created to show the problem fails for another reason
Edit 2:
I have tried to isolate the problem in a minimal crate here
Adding use time::OffsetDateTime is enough to trigger the problem:
The first function build_ok builds, while the second fails with error:

error[E0283]: type annotations needed
  --> src/lib.rs:10:5
   |
10 |     assert_eq!(b1, &[]);
   |     ^^^^^^^^^^^^^^^^^^^ cannot infer type
   |
   = note: multiple `impl`s satisfying `u8: PartialEq<_>` found in the following crates: `core`, `deranged`:
           - impl PartialEq for u8;
           - impl<MIN, MAX> PartialEq<deranged::RangedU8<MIN, MAX>> for u8
             where the constant `MIN` has type `u8`, the constant `MAX` has type `u8`;
   = note: required for `[u8]` to implement `PartialEq<[_; 0]>`
   = note: 1 redundant requirement hidden
   = note: required for `&[u8]` to implement `PartialEq<&[_; 0]>`
   = note: this error originates in the macro `assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)

[ggwpez]

This breaks our code base for downstream users who do not use --locked to compile: paritytech/polkadot-sdk#8121

cargo update -p deranged --precise 0.4.0 for anybody wondering what to do.

[tdkt]

Please release 0.5.0 and then yank 0.4.1. It also messes with From<u16> for usize.

[jhpratt]

Unfortunately there isn't really anything that can be done on my end. The impl is considered acceptable breakage per RFC 1105, and even if it happened in a breaking release the same issue would arise due to it being an indirect (and not publicly exposed) dependency.

[RalfJung]

Something seems off if a crate introduces breakage to entirely unrelated code that isn't even close to any of the types involved in the crate -- maybe this is formally acceptable, but it's not something I encountered before with another crate, and it is not nice to have invasive changes on unrelated code paths in this way.

[chifflier]

Unfortunately there isn't really anything that can be done on my end.

I tend to disagree - there are other solutions than adding a trait that leaks on other crates. Implementing PartialEq for all T might be nice for you own use, but I'm sure this could be implemented another way. Besides, this wasn't present in the previous version.

The impl is considered acceptable breakage per RFC 1105, and even if it happened in a breaking release the same issue would arise due to it being an indirect (and not publicly exposed) dependency.

This RFC covers semver and version numbering. I do not think breaking a default trait implementation for all other crates can be described as an "API change"

I understand the changes you pushed might be nice, but I kindly ask you to reconsider the "wontfix". Maybe this trait can be used only internally (or when imported), or maybe using PartialEq is not possible without leaking.