Hacker News new | ask | show | jobs
by josephg 343 days ago
Yeah; I think this argument makes sense. With perfect derive, #[derive(Clone)] has a bunch of implicit trait bounds which will change automatically as the struct changes. This has semver implications - and so we might want to be explicit about this rather than implicit.

We could solve this by having developers add trait bounds explicitly into the derive macro.

Currently this:

    #[derive(Clone)]
    struct Foo<T>(Arc<T>)
expands to:

    impl Clone for Foo where T: Clone { ... }
Perfect derive would look at the struct fields to figure out what the trait bounds should be. But it might make more sense to let users set the bound explicitly. Apparently the bon crate does it something like this:

    #[derive(Clone(bounds(Arc<T>: Clone)))]
Then if you add or remove fields from your struct, the trait bounds don't necessarily get modified as a result. (Or, changing those trait bounds is an explicit choice by the library author.)