When the compiler says you're missing something
You've written a generic function. It compiles fine in isolation. Then you call it with a specific type and the build collapses with a wall of red text:
error[E0277]: the trait bound `MyType: std::fmt::Display` is not satisfied
--> src/main.rs:10:21
|
10 | print_item(thing);
| ---------- ^^^^^ the trait `Display` is not implemented for `MyType`
| |
| required by a bound introduced by this call
E0277 is, by a wide margin, one of the errors you'll see most often as a Rust learner. The good news is that the compiler is being unusually helpful here. It's telling you exactly which trait is missing and where the requirement comes from. Once you can read the message, the fix is almost mechanical.
What "trait bound not satisfied" actually means
Rust uses traits the way other languages use interfaces or type classes. A trait is a contract: "any type that implements me promises to have these methods." Generic code attaches trait bounds to its parameters: "this function works for any type T, as long as T implements Display."
When you call the function with a concrete type, the compiler checks: does that type actually implement the required trait? If yes, all good. If no, you get E0277. The trait bound, in other words, is a requirement set by the function. The "not satisfied" part means the type you handed in doesn't meet the requirement.
There are three flavors of this error you'll run into:
- The required trait genuinely isn't implemented for your type. You forgot to derive it, or the type doesn't support what you're trying to do.
- The required trait IS implemented, but you forgot to import it (so it's invisible at the call site).
- You're inside generic code and you forgot to declare the trait bound on your own generic, so the compiler can't trust that any caller's type will satisfy it.
Each one has a slightly different fix.
Flavor one: type doesn't implement the trait
The simplest case. You've got a struct, you try to print it with {}, and the compiler complains:
struct Point { x: i32, y: i32 }
fn main() {
let p = Point { x: 1, y: 2 };
println!("{p}"); // E0277: Display not implemented for Point
}
The error message:
error[E0277]: `Point` doesn't implement `std::fmt::Display`
= note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
The compiler even hints at one possible fix: Display is for user-facing output, and Debug is the developer-facing version. If {:?} is what you want, derive Debug:
// `derive` asks the compiler to generate a default impl for us.
// For Debug, that's "print the field names and values."
#[derive(Debug)]
struct Point { x: i32, y: i32 }
fn main() {
let p = Point { x: 1, y: 2 };
println!("{p:?}"); // prints Point { x: 1, y: 2 }
}
If you genuinely need Display, you have to write it yourself, because Display controls user-facing formatting and the compiler can't guess what you want:
use std::fmt;
struct Point { x: i32, y: i32 }
impl fmt::Display for Point {
// The contract: receive a Formatter, write the string output, return Result.
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "({}, {})", self.x, self.y)
}
}
The same pattern applies to lots of other traits: Clone, PartialEq, Hash, Default, Iterator. Either derive (when the compiler can generate a sensible default) or implement by hand (when you have to spell out behavior).
Flavor two: you forgot to import the trait
This one trips up almost everyone the first time. In Rust, a trait's methods only become available when the trait is in scope. Even if a type implements Read, you can't call .read() on a value of that type unless std::io::Read is imported.
use std::fs::File;
// note: no `use std::io::Read;`
fn main() {
let mut f = File::open("data.txt").unwrap();
let mut buf = Vec::new();
f.read_to_end(&mut buf).unwrap(); // E0599 in some versions, E0277 in others
}
The error frequently reads:
error[E0599]: no method named `read_to_end` found for struct `File` in the current scope
= help: items from traits can only be used if the trait is in scope
= help: the following trait is implemented but not in scope; perhaps add a `use` for it:
use std::io::Read;
Sometimes the same situation surfaces as E0277 when generics are involved. Either way, the fix is to add the import:
use std::fs::File;
use std::io::Read; // brings the read_to_end method into scope
When you see "trait is implemented but not in scope," that's your hint. Same goes for traits like Iterator, Write, FromStr, IntoIterator. They all need to be imported at the call site.
Flavor three: missing bound on your own generic
This is the most subtle one. You're writing a generic function or impl block, and the compiler complains because YOUR code is making assumptions you haven't declared:
fn print_item<T>(item: T) {
println!("{item}"); // requires T: Display, which we never said
}
Error:
error[E0277]: `T` doesn't implement `std::fmt::Display`
|
| println!("{item}");
| ^^^^^^^ `T` cannot be formatted with the default formatter
|
help: consider restricting type parameter `T`
|
| fn print_item<T: std::fmt::Display>(item: T) {
| +++++++++++++++++++
The compiler is being a saint here. It even shows you the exact characters to insert. The fix:
// We add the bound: "T must implement Display." Now the println! call
// has a guarantee, and the compiler is satisfied.
fn print_item<T: std::fmt::Display>(item: T) {
println!("{item}");
}
For multiple bounds, use +:
fn debug_clone<T: std::fmt::Debug + Clone>(item: T) -> T {
println!("{item:?}");
item.clone()
}
Or use a where clause when the list gets long:
fn complex_fn<T>(x: T) -> String
where
T: std::fmt::Debug + Clone + Send + 'static,
{
format!("{x:?}")
}
A more realistic example
Say you're writing a small caching helper. It should work for any key type, as long as the key is hashable and comparable. Without bounds, the compiler refuses:
use std::collections::HashMap;
// First attempt: tries to use K as a HashMap key without proving
// that K can be a HashMap key. HashMap requires K: Eq + Hash.
fn store<K, V>(map: &mut HashMap<K, V>, key: K, value: V) {
map.insert(key, value); // E0277: Eq not satisfied
}
The compiler points right at the missing pieces. Add them:
use std::collections::HashMap;
use std::hash::Hash;
// Now K is required to satisfy the same bounds HashMap itself needs.
// V has no requirements because we just store and retrieve it.
fn store<K, V>(map: &mut HashMap<K, V>, key: K, value: V)
where
K: Eq + Hash,
{
map.insert(key, value);
}
The mental model: every operation you do inside generic code becomes a requirement on the generic. If you call .clone(), you need Clone. If you compare with ==, you need PartialEq. If you print with {}, you need Display. The compiler tracks all of these for you and asks you to declare the same ones in the function signature.
Common pitfalls
You added the bound to the function but the error keeps appearing on the struct. Check whether the struct itself is generic. If you have struct Cache<T> and use T in a way that requires Hash, you may need the bound on the struct definition (or just on the impl that uses it; bounds on structs are sometimes considered a smell for this reason).
You're getting an error that mentions a trait you've never heard of, like Sized or ?Sized. By default, all generic parameters are assumed to be Sized. If the error says something is not Sized, you may need T: ?Sized (relaxed bound) or you may need to box the value.
The error mentions a trait that's clearly implemented for your type. Two possibilities. Either the trait isn't in scope (flavor two: add the use). Or the implementation requires its own conditions you haven't met. For example, Vec<T>: Clone only when T: Clone. So Vec<File> isn't Clone because File isn't.
You added a derive macro and the compiler still complains. Some derives have their own requirements: #[derive(Hash)] requires every field to be Hash. If even one field doesn't implement it, the derive fails too. Read the longer error: it usually points at the offending field.
Cyclic bounds: T: Foo requires T: Bar, but Bar requires Foo. You'll see "overflow evaluating the requirement" or similar. Usually means a typo in the bound, or that you need to break the cycle with a fresh trait.
When to use what
Reach for derive macros first. Debug, Clone, PartialEq, Default, Hash are derivable for almost any plain data type and you should usually take the freebie.
Implement traits by hand when behavior matters: Display (formatting), Iterator (iteration), Drop (cleanup), From/Into (conversions). The compiler can't guess these.
Add explicit bounds on generic functions whenever you call a method that requires them. Don't try to be clever with implicit bounds: spell them out, and your error messages get clearer for the next reader.
Use where clauses once you have more than two bounds or when the bounds are on associated types (where I: Iterator<Item = u32>). They scale better than inline bounds.
Where to go next
E0277 is one chapter of a much bigger story about how Rust's type system tracks correctness.
How to Read Rust Compiler Error Messages