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

impl Eq/PartialEq for MeshMaterial{2|3}d #17990

Merged
merged 1 commit into from
Feb 24, 2025

Conversation

jnhyatt
Copy link
Contributor

@jnhyatt jnhyatt commented Feb 23, 2025

Objective

Eq/PartialEq are currently implemented for MeshMaterial{2|3}d only through the derive macro. Since we don't have perfect derive yet, the impls are only present for M: Eq and M: PartialEq. On the other hand, I want to be able to compare material components for my toy reactivity project.

Solution

Switch to manual Eq/PartialEq impl.

Testing

Boy I hope this didn't break anything!

@jnhyatt jnhyatt added D-Trivial Nice and easy! A great choice to get started with Bevy C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Feb 23, 2025
@alice-i-cecile alice-i-cecile added A-Rendering Drawing game state to the screen S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it labels Feb 23, 2025
@hukasu
Copy link
Contributor

hukasu commented Feb 23, 2025

why exactly does the derive not works for M that are not PartialEq or Eq?

and what about adding PartialEq and Eq to the required traits of Material2d and Material3d?

pub trait Material2d:
    Sized
    + AsBindGroup
    + Asset
    + Clone
    + PartialEq
    + Eq;

@hukasu
Copy link
Contributor

hukasu commented Feb 23, 2025

and for testing you could run cargo run -p ci

add CARGO_BUILD_JOBS and RUST_TEST_THREADS to the env to prevent OOM

@alice-i-cecile
Copy link
Member

why exactly does the derive not works for M that are not PartialEq or Eq?

This is a standard Rust problem: "perfect derive" is the name of the solution for this. The derive macros assume that the internal types must also be compared, but when you're using things like PhantomData that isn't the case.

and what about adding PartialEq and Eq to the required traits of Material2d and Material3d?

Generally, we should try to avoid adding bounds without a good reason, and prefer to add them at methods etc. It's less verbose to work with and more flexible.

@jnhyatt
Copy link
Contributor Author

jnhyatt commented Feb 23, 2025

@hukasu There shouldn't be any behavior changes. Tests run before merging anyway, that's why I didn't bother running tests locally.

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Feb 23, 2025
Merged via the queue into bevyengine:main with commit 2953db7 Feb 24, 2025
34 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Usability A targeted quality-of-life change that makes Bevy easier to use D-Trivial Nice and easy! A great choice to get started with Bevy S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants