Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More general PartialEq implementation for Option #1239

Open
tomjakubowski opened this issue Aug 6, 2015 · 5 comments
Open

More general PartialEq implementation for Option #1239

tomjakubowski opened this issue Aug 6, 2015 · 5 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@tomjakubowski
Copy link
Contributor

Currently, only the case where T == U is covered. Presumably this is because of derive limitations, since this impl is indeed derived in libcore.

I believe it should be possible and correct to provide the following impl:

impl<T, U> PartialEq<Option<U>> for Option<T> where T: PartialEq<U>, U: PartialEq<T> {
    fn eq(&self, rhs: &Option<U>) -> bool {
        match (self, rhs) {
            (&Some(ref lhs), &Some(ref rhs)) if lhs == rhs => true,
            (&None, &None) => true,
            _ => false
        }
    }
}
@tomjakubowski tomjakubowski changed the title impl<T, U> PartialEq<Option<U>> for Option<T> where T: PartialEq<U> More general PartialEq implementation for Option Aug 6, 2015
@Aatch
Copy link
Contributor

Aatch commented Aug 11, 2015

Seems reasonable to me. Though I wonder if both T: PartialEq<U> and U: PartialEq<T> are necessary.

@tomjakubowski
Copy link
Contributor Author

Seems reasonable to me. Though I wonder if both T: PartialEq and U: PartialEq are necessary.

Ahh yes, that was a little cuteness that snuck in. Shouldn't be necessary to have both.

@withoutboats
Copy link
Contributor

👍 Are there any similar impls on Option or Result that could be made more general?

@huonw
Copy link
Member

huonw commented Aug 11, 2015

This is a subset of rust-lang/rust#20063, and has in fact had a failed attempt as part of that issue: rust-lang/rust#20063 (comment) .

@nrc nrc added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Aug 25, 2016
@Centril
Copy link
Contributor

Centril commented Oct 7, 2018

Triage: No movement since 2015.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

6 participants