impl PartialEq<Option<&OsStr>> for Option<&str>

[pickfire]

Allows path.extension() == Some("ext")
Long alternative path.extension().map_or(false, |ext| ext == "ext")
I wish if let Some("ext") = path.extension() works too

[rust-highfive]

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

[meithecatte]

This seems oddly specific. Perhaps we should implement Option<T>: PartialEq<Option<U>> where T: PartialEq<U> instead?

[pickfire]

Ah, that does seem possible. I thought about that but I am not sure if that's useful. Should I change it?

[meithecatte]

It's definitely useful in more situations :)

[pickfire]

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=116c68acaf357ee257833ed6d4ea4915

   Compiling playground v0.0.1 (/playground)
error[E0119]: conflicting implementations of trait `std::cmp::PartialEq<Op<_>>` for type `Op<_>`:
  --> src/lib.rs:1:10
   |
1  |   #[derive(PartialEq, Eq)]
   |            ^^^^^^^^^ conflicting implementation for `Op<_>`
...
17 | / impl<T, U> PartialEq<Op<T>> for Op<U>
18 | | where
19 | |     T: PartialEq<U>,
20 | | {
...  |
26 | |     }
27 | | }
   | |_- first implementation here
   |
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to previous error

For more information about this error, try `rustc --explain E0119`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.

It doesn't seemed to work though.

[meithecatte]

That's because the manually-implemented PartialEq also covers the case that derive(PartialEq) implements. You would need to remove the derive.

[pickfire]

That's because the manually-implemented PartialEq also covers the case that derive(PartialEq) implements. You would need to remove the derive.

Ah, I didn't know that. Let me check again.

[pickfire]

@NieDzejkob It seemed to be breaking chance to do that.

impl<T, U> PartialEq<Op<T>> for Op<U>
where
    T: PartialEq<U>,
    U: PartialEq<T>,
{
    #[inline]
    fn eq(&self, other: &Op<T>) -> bool {
        self.as_ref()
            .zip(other.as_ref())
            .map_or(false, |(x, y)| x == y)
    }
}

#[test]
fn derive_partialeq() {
    use std::ffi::OsStr;
    assert_eq!(Op::Some("a"), Op::Some("a"));
    assert_eq!(Op::Some("a"), Op::Some(OsStr::new("a")));
    // assert_ne!(Op::Some("a"), Op::None); // does not compile
    assert_ne!(Op::Some("a"), Op::None::<&str>);
}

[meithecatte]

Hmm, I'm out of my depth here, but perhaps there is a special feature that could be used to disambiguate this.

[bors]

☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

@pickfire Ping from triage: can you please address the merge conflict and build failures?

[pickfire]

@JohnCSimon No, I will be creating a new patch for this in another pull request.

[pickfire]

The build breaks because I cannot impl for Option<&OsStr>. I am not sure how to implement stuff not in core but in std. How do I do that?

[pickfire]

@crlf0710 I need help on this, I don't know how to fix it.

[jonas-schievink]

I don't think this is implementable without the breaking change pointed out in #74369 (comment)

[pickfire]

So I need to close this?

[crlf0710]

IIRC unfortunately i don't think this is currently possible without Option being #[fundamental], which it is not.

IIRC if let Some("ext") = path.extension() would be supported after RFC 2500 is implemented. I've created a topic on zulip. RFC 2295 is implemented(zulip topic), which seems to depend on the implementation of RFC 2500 (zulip topic).

[Dylan-DPC-zz]

Closing this based on the above comments. If you have a better way to do this you can submit a new PR :)