Currently deriving the “standard” traits such as Debug and PartialEq for structs requires that all the fields implement the trait in question. For some traits this is a hard requirement; one could hardly imagining .clone()ing a struct whose all fields are not cloneable. However, there are some cases where more flexibility is warranted.
The main motivator for more flexible deriving is Debug: there often are cases where you want to inspect the state of some struct using debug printing or logging, only to find that you can’t derive Debug for it because one of the fields don’t implement it, and have to painstakingly hand-roll the implementation for a simple peek.
Similar, although maybe not as pressing usecases come forth when writing tests. Very often you want to assert_eq! the result value with some expected value. In my experience, sometimes you just want to build a “similar enough” object to tests against some returned object state – if the same object contains some opaque fields, you don’t neccessarily want to test them, but the other ones. This requires the object to implement PartialEq, which it may not do because of the “opaque” fields.
I think it would be beneficial at least for these two trait derivations to have Serde-like field attributes. For those unfamiliar with Serde, it allows easiy customisation of derives of Serialize and Deserialize using attributes on fields:
#[derive(Serialize, Deserialize)]
struct Point {
x: i32,
y: i32,
#[serde(skip)]
debug_data: SomeData,
}
I am proposing that the derives of Debug and PartialEq would have similar supported attributes such as #[debug(ignore)] or #[partial_eq(ignore)]. (The actual syntax is bikesheddable.) This would help with some small but irritating papercuts that manifest themselves especially when doing debugging, testing and prototyping work, where quickness and ease are of paramount importance.
I’d like to write an RFC around this, but I’d like to gather some feedback first. Is there any show-stoppers for this? I think there is certainly demand.
