Add attributes for generating Eq/PartialEq/Ord/PartialOrd/Hash#76
Add attributes for generating Eq/PartialEq/Ord/PartialOrd/Hash#76jrb0001 wants to merge 1 commit into
Conversation
|
First of all, thanks for your contribution. I am however not sure it's a good idea. Should we really ignore unused bits in equality comparisons? I think a point could be made either way, so I'm a little hesitant to actually make a call here (if anything, I'd probably have opted for the opposite and included the unused bits - basically, just have PartialEq and Eq forward to the inner value). Similarly for comparisons: Is declaration order really such an obvious one? So far, declaration order doesn't affect behavior in any way, so this would suddenly put some meaning on it. Not saying we don't want this, but I think we need a bit of a discussion on why these are the choices that feel natural to you. What problem is this solving? |
|
You can generate standard derive implementations by paying attention to the order of the struct attributes. example 2 use bitbybit::bitfield;
use std::hash::{DefaultHasher, Hash};
// BAD! `raw_value` does not exist yet and will be ignored
#[derive(PartialEq, Eq, PartialOrd, Ord, Hash)]
#[bitfield(u32)]
struct BadDerives {}
#[bitfield(u32)]
// GOOD! `raw_value` exists and will be used
#[derive(PartialEq, Eq, PartialOrd, Ord, Hash)]
struct GoodDerives {}
pub fn test_standard_derive() {
let a = GoodDerives::new_with_raw_value(1);
let b = GoodDerives::new_with_raw_value(2);
assert!(a == GoodDerives::new_with_raw_value(1));
assert!(a != b);
assert!(a < b);
assert!(a.hash(&mut DefaultHasher::new()) == 1u32.hash(&mut DefaultHasher::new()));
assert!(b.hash(&mut DefaultHasher::new()) == 2u32.hash(&mut DefaultHasher::new()));
} |
This adds attributes to generate
Eq/PartialEq/Ord/PartialOrd/Hashimpls. Inspired by theDebugimpl from #70.