Checkpoint: Traits & Generics

Reviewed & published by Brayan K

This checkpoint consolidates everything from the traits-and-generics chapter — trait objects, associated types, derive macros, operator overloading, Default/Clone, testing, file I/O, and command-line arguments — into one build challenge you write and run yourself.

Part of the free Rust course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

Work through the recap, complete the multi-step shapes program, reveal the full solution to compare, and test your understanding with the checkpoint quiz.

What This Checkpoint Covers

• Trait objects: dyn Trait and Box<dyn Trait>
• Associated types and trait bounds
• Derive macros (Debug, Clone, Ord, ...)
• Operator overloading via std::ops
• Default & Clone for construction and copies
• Testing, file I/O, and command-line args

📚 Chapter Recap

• 🔹 Trait objects: dyn Trait behind a pointer (&dyn or Box<dyn>) lets mixed types share an interface via dynamic dispatch; generics give static dispatch for one type.
• 🔹 Associated types & bounds: type Item; is a slot the implementor fills (as in Iterator); <T: Trait> and where constrain generics, combined with +.
• 🔹 Derive macros: #[derive(...)] auto-writes Debug, Clone, PartialEq, Hash, the ordering set, and Default (Copy needs all-Copy fields).
• 🔹 Operator overloading: implement std::ops traits (Add, Sub, Mul, AddAssign, Index) so operators work on your types, each with its Output.
• 🔹 Default & Clone: Default::default() and ..Default::default() build starting values; Clone is an explicit deep copy, Copy an implicit cheap one.
• 🔹 Testing, file I/O, CLI: #[test] + cargo test; fs::read_to_string/fs::write + BufReader; env::args() and env::var().

🛠️ Build Challenge: A Shapes Program

Put the chapter to work. You'll define a Shape trait with an area() method, implement it for several #[derive(Debug)] structs, store them in a Vec<Box<dyn Shape>>, and sort them by area. Start with the smaller starter below, fill the two blanks, then grow it toward the full solution.

// 🎯 BUILD CHALLENGE (starter) — fill the blanks, then extend it (see below).
trait Shape {
    fn area(&self) -> f64;
    fn name(&self) -> &str;
}

#[derive(Debug)]
struct Square { side: f64 }
#[derive(Debug)]
struct Circle { radius: f64 }

impl Shape for Square {
    fn area(&self) -> f64 { self.side * self.____ }     // 👉 a square's area
    fn name(&self) -> &str { "Square" }
}
impl Shape for Circle {
    fn area(&self) -> f64 { 3.14159 * self.radius * self.radius }
    fn name(&self) -> &str { "Circle" }
}

fn main() {
    // 👉 a heterogeneous list needs boxed trait objects: Box<dyn Shape>
    let shapes: Vec<Box<dyn ____>> = vec![
        Box::new(Square { side: 2.0 }),
        Box::new(Circle { radius: 1.0 }),
    ];

    for s in &shapes {
        println!("{} area = {:.2}", s.name(), s.area());
    }
}

// ✅ Expected output:
//    Square area = 4.00
//    Circle area = 3.14

Now extend it: add a Rectangle and a Triangle, give Shape a name() method, sort the shapes by area with sort_by, print a running total, and report the largest. When you're ready, reveal the full solution to compare.

A complete, runnable solution with three shapes, sorting by area, a total, and the largest shape:

📝 Checkpoint Quiz

Answer each in your head, then click to reveal. If any trips you up, revisit the linked idea before moving on to the capstone.

Because a dyn Trait has no fixed size known at compile time — different implementors have different sizes. A pointer has a known size, so the trait object is stored behind &, Box, Rc, etc. (it's a fat pointer: data pointer + vtable pointer).

Static dispatch (generics, <T: Trait>) resolves method calls at compile time and generates a specialized copy per type — fast, often inlined. Dynamic dispatch (trait objects, dyn Trait) looks up the method at runtime through a vtable — one copy of the code, slightly slower, but able to mix types.

Copy requires every field to be Copy, so a struct with a String or Vec field can't be Copy. Derive Clone instead and call .clone() explicitly. (And Copy always requires Clone too.)

+ uses std::ops::Add; a + b compiles to a.add(b). Its associated Output type names what the operation produces — often Self, but it can differ (e.g. multiplying a vector by an f64 still yields the vector type).

Add #[should_panic(expected = "...")] above a #[test] to require a panic. To use ? inside a test, give the test a return type of Result<(), E> and end with Ok(()).

Index 0 is the program's own name, so real arguments start at index 1. Convert an argument String to a number with parse and a type annotation, handling the Result — e.g. let n: i64 = arg.parse().unwrap_or(0);.

Pro Tips

• 💡 Reach for generics first, trait objects when you genuinely need to mix types in one collection.
• 💡 Derive liberally: Debug on nearly everything makes debugging and tests painless.
• 💡 Sort floats with sort_by and partial_cmp, since f64 isn't Ord.

🎉 Checkpoint Complete!

• ✅ You combined a trait, derive macros, and a Vec<Box<dyn Shape>> in one program
• ✅ You sorted by a computed f64 with sort_by + partial_cmp
• ✅ You reviewed associated types, operator overloading, Default/Clone, testing, file I/O, and CLI args
• ✅ You checked your understanding with the quiz

Practice quiz

Continue this course

• Previous: Command-Line Args (std::env)
• Next: More Collections: VecDeque, BTreeMap & BinaryHeap — Pick the right collection — deques, sorted maps, heaps, and sets
• Quick reference: Rust cheat sheet

Frequently asked questions

What should I be able to do after this checkpoint?

You should be comfortable defining a trait and implementing it for several types, choosing between generics (static dispatch) and trait objects (dynamic dispatch), and storing mixed types in a Vec<Box<dyn Trait>>. You should also be able to derive common traits like Debug, Clone, PartialEq, and the ordering set; overload operators through std::ops; supply Default values; write tests with #[test] and cargo test; read and write files with std::fs; and read command-line arguments and environment variables with std::env. The build challenge below exercises several of these at once.

Why does the solution use sort_by with partial_cmp instead of sort?

The shapes are compared by area, which is an f64. Floating-point numbers implement PartialOrd but not Ord, because the special value NaN is not ordered relative to anything, so the plain sort method (which requires Ord) is not available. sort_by lets you pass a closure that returns an Ordering, and partial_cmp produces an Option<Ordering> that we unwrap, which is safe here because real areas are never NaN. This is the standard pattern for sorting floats.

When would I pick a trait object over a generic here?

Use a trait object, as the shapes Vec does, when you need to store or process values of several different concrete types together behind one interface — a generic Vec<T> can only hold one type at a time. Use a generic function or struct when each call site works with a single known type and you want the speed of static dispatch and inlining. The shapes program needs a mixed collection, so Vec<Box<dyn Shape>> is the right tool; a function that only ever sorts one shape type could be generic instead.

How do I run the build challenge myself?

Put the code in a file such as main.rs inside a Cargo project and run cargo run, or paste it straight into the Rust Playground and press Run. The starter is a smaller version with two blanks to fill; once that compiles and prints the two areas, extend it toward the full solution by adding more shapes, deriving Debug, and sorting by area. The expected output is shown beneath each block so you can check your work exactly.