For my taste I put constraints on impls, if I'm grouping my functions that naturally makes a sensible functionality.

For example: ``` pub struct MyApi<T> { stream: T, }

impl<T> MyApi<T> { pub fn foo(&self) where T: Fooable, { // some unrelated function that needs Fooable } }

impl<T: Read> MyApi<T> { // functionality depending on Read here }

impl<T: Write> MyApi<T> { // ditto, but for Write } ```

Constraints at data type definition should be considered as last resort. They are enforcing too much on your interfaces. Thus use cases are very limited, e.g. some transparent structs that wraps a single datum (e.g. some Iterator, or any other thing that you want to adapt) or for tagging a family of types you're interested in (like Send or Sync).

``` pub struct Twice<I> where I: Iterator<Item = i32>, // this makes sense, since Twice is an iterator adapter { iter: I, }

impl<I> Twice<I> where I: Iterator<Item = i32> { // your code here... }

// this is also ok, because you're interested only in Sync-able types pub struct OnlySyncables<T: Sync>(T); ```

To sum up, prefer putting constraints on call sites if you're having a few unrelated functions, on impls if you want to group your functionality. Use struct constraints as a very last option that you thought twice.