Warn about trait bounds on struct and enum type parameters

[dtolnay]

Traits are for behavior.

impl<T> Data<T> where T: Behavior { /* behavior, okay */ }

fn behave<T>() where T: Behavior { /* also behavior, also okay */ }

struct Data<T> where T: Behavior { /* DON'T DO THIS */ }

The only exception is things like Cow that use associated types to define data.

My current understanding is that any data structure not using associated types should not have trait bounds (?Sized doesn't count). Redundant bounds like this suck because they transitively infect anything that names the type in any way. Consider this enum.

#[derive(Clone, Debug, Eq, PartialEq, Serialize, Deserialize)]
enum Compact<T: CompactPart, H: Serialize + Deserialize + Clone + 'static> {
    Decrypted {
        header: Header<H>,
        payload: T,
    },
    Encrypted(Encrypted),
}

// kill me
fn print_the_thing<T, H>(c: Compact<T, H>)
    where T: CompactPart + Debug,
          H: Serialize + Deserialize + Clone + 'static + Debug
{
    println!("{:?}", c);
}

Without trait bounds on the data structure:

fn print_the_thing<T: Debug, H: Debug>(c: Compact<T, H>) {
    println!("{:?}", c);
}

[dtolnay]

@oli-obk I think this would help a lot with people trying to write Deserialize<'de> bounds on their types. Almost all the struggles I've seen have been on structs, not so much on functions, and the answer is always just don't put a trait bound there.

[Manishearth]

Hm, this is an interesting lint. Unsure if it should be warn by default; probably should.

[dtolnay]

I believe it should warn by default as long as we can reliably detect the use of an associated type.

[clarfonthey]

Fun fact: a few libstd types could benefit from these changes.

[dtolnay]

Which ones did you find? I found:

• std::char::DecodeUtf8
• std::char::DecodeUtf16
• std::collections::binary_heap::BinaryHeapPlace
• std::collections::binary_heap::PeekMut
• std::slice::Split
• std::slice::SplitMut
• std::slice::SplitN
• std::slice::SplitNMut
• std::slice::RSplitN
• std::slice::RSplitNMut

[clarfonthey]

For the longest time BinaryHeap was on that list too, but it appears to have been fixed! It's been a while since I checked but it appears that all of the iterator adapters have been fixed for this too.

[dtolnay]

For the longest time before 2013 rust-lang/rust@6ce7446#diff-76432ae7ccf0520cf36aac7c006809a3 😉

[oli-obk]

Won't the error messages quality decrease if those bounds are as late as possible? Especially for iterator adaptors? Don't know about any of the conversations on this topic, so I might be mixing some. A specialized version for a whitelist of bounds would probably be a good start. Things like debug, partialeq, deserialize...

[llogiq]

I'd also like to see how such a lint would fare against typenum.

[dtolnay]

I'd also like to see how such a lint would fare against typenum.

Perfectly fine. I tried removing all trait bounds from structs in typenum and it still compiles and passes all tests.

[dtolnay]

Won't the error messages quality decrease if those bounds are as late as possible? Especially for iterator adaptors?

@oli-obk could you put together an example with before and after code? I don't think this could happen. Errors are triggered when you rely on behavior, and we would be keeping trait bounds on behavior.

[llogiq]

cc @paholg

[paholg]

It's beyond the scope of clippy, but I would like to see the opposite; that putting a constraint on a struct implicitly adds that constraint to all impls of that struct. This would mean that removing constraints would become a potentially breaking change, though.

As is, removing constraints from structs shouldn't break things, but it moves information on how the struct should be used from the type signature into documentation.

[dtolnay]

Constraints on a struct implying the same constraints on all impls is an orthogonal discussion. Even with that feature, I would strongly disagree with putting trait bounds on data and I think this lint would still be valuable.

Consider Vec<T>. You can clone a vec if you can clone T. You can serialize a vec if you can serialize T. You can deserialize a vec if you can deserialize T.

Look at the code I linked to in the top comment. I see this all the time. It is the equivalent of writing:

#[derive(Clone, Serialize, Deserialize)]
struct Vec<T> where T: Clone + Serialize + Deserialize { /* ... */ }

Yes your crate may compile either way. Yes "information on how the struct should be used [is in] the type signature [not] documentation." But no it's not valuable in any way.

[paholg]

It's not valuable for a general purpose struct like Vec, but for something like typenum, it makes sense. The structs defined in typenum are not designed to have any parameters except those defined inside the crate.

I think this lint could be valuable, too, and I should have expressed that in the previous comment. It's easy enough to disable in the rare cases when you don't want it.

[dtolnay]

Makes sense. On a spectrum between Vec<T> and typenum::PInt<U>, where do you think the Compact<T, H> type stands? And as a fraction of types how common do you think the typenum situation of opting out of this lint would be?

[llogiq]

I think the typenum case isn't so common – indeed I hope it goes away sooner than later, once Rust's type system can express integers directly.

Another crate I know that uses generic constraints a lot is diesel. Perhaps @killercup can tell us about their uses?

[killercup]

I haven't read the whole issue thread, but let me chime in regardless :)

I'm pretty sure that since most public data structures contain some private fields (and they typically should for forwards compat reasons), they also have at least one associated constructor method (usually new). Adding constraints to this impl might not be as descriptive as adding them to the struct, but still results in the same thing.

As far as I can see grep, diesel's main crate only has a handful of type constraints used in structs, and only RawBytesBindCollector and Nullable are public. (And Nullable uses it to restrict recursion.)

As for private structs, it's possible/easier to just use the type constructors, so you need to keep track of the intended constraints yourself, or add them to your struct.

[kennytm]

This lint would be pointless if (big if) implied bounds is solved.

[dtolnay]

As discussed in https://github.com/Manishearth/rust-clippy/issues/1689#issuecomment-296396580, this lint would be valuable whether or not implied bounds are solved. The typenum-like cases where you would want to opt out are rare.

[kennytm]

@dtolnay It think it makes sense for structures like HashMap<K, V>, which is useless unless K: Eq + Hash. By the time implied-bounds is really landed the lint could be changed to allow-by-default.

[dtolnay]

I would disagree with allow-by-default even after implied bounds have landed.

Let's look at the motivating example again. Keep in mind that this is real code written by a real live Rust user of the sort that would rely on Clippy for guidance in navigating the complicated world of Rust types.

#[derive(Clone, Debug, Eq, PartialEq, Serialize, Deserialize)]
enum Compact<T: CompactPart, H: Serialize + Deserialize + Clone + 'static> {
    Decrypted {
        header: Header<H>,
        payload: T,
    },
    Encrypted(Encrypted),
}

Oh but we'd like to add a PartialOrd impl because it is needed for some new code. Easy enough:

- #[derive(Clone, Debug, Eq, PartialEq, Serialize, Deserialize)]
- enum Compact<T: CompactPart, H: Serialize + Deserialize + Clone + 'static> {
+ #[derive(Clone, Debug, Eq, PartialEq, Serialize, Deserialize, PartialOrd)]
+ enum Compact<T: CompactPart, H: Serialize + Deserialize + Clone + PartialOrd + 'static> {

Boom, breaking change. Whether or not there are implied bounds. In general this pattern conflicts with the ways we like to think about adding functionality to data structures.

The HashMap case is what we mean by the rare exceptions. Everyday code is much more like the code in this comment.

[devyn]

Following this has generally made my code nicer, but I have found one little hiccup that I'm not quite sure what to do about.

Including trait bounds in the data definition allows access to associated items inside traits. This is often done with traits such as Iterator, Future, and Stream.

In my case I'm writing a stream adaptor that contains a buffer of items, but I think Peekable is a good enough analogy:

pub struct Peekable<S: Stream> {
    stream: Fuse<S>,
    peeked: Option<S::Item>,
}

This is taken from peek.rs in futures.

If we want to write this without the S: Stream bound, our only option is:

pub struct Peekable<S, T> {
    stream: Fuse<S>,
    peeked: Option<T>,
}

and then to include a where S: Stream<Item=T> bound on the implementations. However this makes the types when fully written out a lot longer and potentially include duplication of T at many different layers. If you're in a situation where automatic typing is not an issue, this is probably okay although leads to less than ideal errors. But if ever anyone has to write out multiple layers of this, it's a real problem.

However, including the S: Stream bound on the struct is also problematic for the same sort of reason others have mentioned: if there are excessive trait bounds on the implementation of Stream for a given type you want to use with it inside another structure, you have to make sure that structure also has all of those required as trait bounds in some way. So you may run into the same problem eventually.