Skip to content
← All tracks

Generics and Traits

Rust

Write code once for many types and name precisely the behaviour you depend on. The track that converts std's documentation from noise into a reference.

This track is written for Rust, which isn't the mode you're browsing in.

0 / 20 solved · 4 articles
  1. 1. Not solved yet. Traits as shared behaviour
  2. 2. Not solved yet. Generic functions and monomorphisation
  3. 3. Not solved yet. Trait bounds and why f64 is not Ord
  4. 4. Not solved yet. where clauses and the bound you cannot write inline
  5. 5. Not solved yet. A generic Stack, and conditional impl blocks
  6. 6. Not solved yet. Display, Debug, and the ToString blanket impl
  7. 7. The comparison traits, read as a design Read
  8. 8. Not solved yet. Supertraits and default methods
  9. 9. Not solved yet. From, Into, and your first blanket impl with teeth
  10. 10. Not solved yet. TryFrom, TryInto, and the type that cannot exist
  11. 11. Not solved yet. AsRef, Borrow, and signatures your callers can actually use
  12. 12. Not solved yet. Deref and the coercion you have been using all along
  13. 13. Not solved yet. Deref polymorphism, and the day your method disappears
  14. 14. How `x.foo()` actually resolves Read
  15. 15. Not solved yet. Operator overloading: + is just a trait method
  16. 16. Not solved yet. Associated type or generic parameter?
  17. 17. Not solved yet. impl Trait in argument position is not a generic
  18. 18. Not solved yet. Returning impl Trait, and what edition 2024 changed
  19. 19. Not solved yet. Blanket impls, and why you can never carve out an exception
  20. 20. Not solved yet. The orphan rule and the newtype escape
  21. 21. Not solved yet. Extension traits: adding methods to types you do not own
  22. 22. Not solved yet. Sealed traits: public to use, closed to implement
  23. 23. Traits with no methods: Copy, Sized, Send, Sync Read
  24. 24. #[derive] lies about its bounds Read

Check yourself

4 questions · one attempt each

These do not count toward finishing the track. They are here to catch the things that are easy to read past.

0 / 4

What is the difference between returning impl Iterator and Box<dyn Iterator>?

fn a() -> impl Iterator<Item = u8> { (0..3).map(|x| x as u8) }
fn b() -> Box<dyn Iterator<Item = u8>> { Box::new(0..3) }
Question 1 of 4