Misplaced trait bounds using derive in stdlib

In this PR for stdlib I had to manually implement Clone and Debug because #[derive] insists on placing bounds on the struct definition for Clone/Debug, which is not what we want. The problem seems to be #26925, which has been open for quite a while.

Is there a quirk for working around this problem or is there a "policy" for those manual implementations, besides marking them as FIXME?

This is an intentional choice for semver -- making the bounds apply to the type parameters means that its behaviour is independent from the implementation choices for which fields are in the struct. It would be easy for the macro to generate bounds for each of the field types instead, but that's intentionally not done so that changing private fields doesn't change when the trait is derived.

I don't think these are even worth a FIXME, since that's just how things intentionally work, and putting a note about it on every implementation that's manual because it it isn't helpful.

Should there be a way to specify bounds explicitly in derive in the future (see proposals such as RFC: Generic parameters in derive by mzabaluev · Pull Request #2811 · rust-lang/rfcs · GitHub), then of course the standard library would plausibly start using it to replace some manual implementations.

4 Likes