Skip to content

Add support for custom equality functions in Eq/PartialEq#535

Open
fredszaq wants to merge 5 commits into
JelteF:masterfrom
fredszaq:with_support_for_eq_and_partialeq
Open

Add support for custom equality functions in Eq/PartialEq#535
fredszaq wants to merge 5 commits into
JelteF:masterfrom
fredszaq:with_support_for_eq_and_partialeq

Conversation

@fredszaq
Copy link
Copy Markdown
Contributor

@fredszaq fredszaq commented Jan 13, 2026

Synopsis

This adds the possibility to use custom functions to perform the equality check in PartialEq/Eq derives. This is quite useful when wrapping types without a PartialEq/Eq impl

Solution

This builds on #532 and reuse the FieldAttributes for Hash, I moved the struct to utils::attr and renamed it WithOrSkip.

I removed fields types that have a with attribute from the automatically added where Type: Eq bound automatically generated by the Eq derive. This seems like the thing to do as if you're using a custom function it most probably means the field doesn't implement Eq.

While this is not part of the roadmap for PartialEq, defined in #163 this is something that will be quite useful for people migrating form derivative as this was something supported by this crate

Checklist

  • Documentation is updated (if required)
  • Tests are added/updated (if required)
  • CHANGELOG entry is added (if required)

@fredszaq fredszaq force-pushed the with_support_for_eq_and_partialeq branch from 769f3fe to 197f615 Compare January 27, 2026 09:44
@fredszaq fredszaq mentioned this pull request Mar 3, 2026
3 tasks
@fredszaq fredszaq force-pushed the with_support_for_eq_and_partialeq branch 3 times, most recently from adf44d2 to f9fc07d Compare March 13, 2026 10:01
@fredszaq fredszaq force-pushed the with_support_for_eq_and_partialeq branch from f9fc07d to d090b1a Compare May 11, 2026 09:23
@fredszaq fredszaq force-pushed the with_support_for_eq_and_partialeq branch from 6996bf2 to e8ac838 Compare May 11, 2026 09:49
@fredszaq fredszaq marked this pull request as ready for review May 11, 2026 09:56
@fredszaq
Copy link
Copy Markdown
Contributor Author

@tyranron rebased and removed the draft status on this one as #532 is now merged. Feel free to review when you have time :)

@fredszaq fredszaq mentioned this pull request May 11, 2026
3 tasks
@tyranron tyranron added feature New derive or feature k::api Related to API (application interface) labels May 17, 2026
@tyranron tyranron added this to the 3.0.0 milestone May 17, 2026
Comment thread tests/eq.rs Outdated
#[derive(Eq, PartialEq)]
struct Foo(#[partial_eq(with(eq_special))] NotPartialEq);
#[derive(Eq, PartialEq)]
struct Bar(#[eq(with(eq_special))] NotPartialEq);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fredszaq I don't really like the idea of having #[eq(with(...))] attribute. For skip it has sense, since skipping for Eq and PartialEq is essentially the same thing. with(...), however, has only sense for the PartialEq. Of course, derive(Eq) should account for the #[partial_eq(with(...))] presence. But having the #[eq(with(...))] attribute confuses me a lot, implying that Eq trait has a method, which is not the case.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. I also added an error if you have #[derive(Hash)] with partial_eq(with) and no hash(skip/with)

Comment thread impl/src/cmp/partial_eq.rs Outdated

/// Mapping from [`syn::Field`] marked with an [`attr::With`] to the [`syn::Path`] of the alternate
/// eq function.
type FieldsWithAlternateEqFunction = HashMap<usize, syn::Path>;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fredszaq let's stick to the same terminology everywhere and just call it "custom function".

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done, changed also on the hash derive that was also using the alternate terminology

@fredszaq fredszaq requested a review from tyranron May 18, 2026 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature New derive or feature k::api Related to API (application interface)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants