We can't find the internet
Attempting to reconnect
Something went wrong!
Attempting to reconnect
← All tracks
0 / 4
Generics and Traits
RustWrite 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. Not solved yet. Traits as shared behaviour
- 2. Not solved yet. Generic functions and monomorphisation
- 3. Not solved yet. Trait bounds and why f64 is not Ord
- 4. Not solved yet. where clauses and the bound you cannot write inline
- 5. Not solved yet. A generic Stack, and conditional impl blocks
- 6. Not solved yet. Display, Debug, and the ToString blanket impl
- 7. The comparison traits, read as a design Read
- 8. Not solved yet. Supertraits and default methods
- 9. Not solved yet. From, Into, and your first blanket impl with teeth
- 10. Not solved yet. TryFrom, TryInto, and the type that cannot exist
- 11. Not solved yet. AsRef, Borrow, and signatures your callers can actually use
- 12. Not solved yet. Deref and the coercion you have been using all along
- 13. Not solved yet. Deref polymorphism, and the day your method disappears
- 14. How `x.foo()` actually resolves Read
- 15. Not solved yet. Operator overloading: + is just a trait method
- 16. Not solved yet. Associated type or generic parameter?
- 17. Not solved yet. impl Trait in argument position is not a generic
- 18. Not solved yet. Returning impl Trait, and what edition 2024 changed
- 19. Not solved yet. Blanket impls, and why you can never carve out an exception
- 20. Not solved yet. The orphan rule and the newtype escape
- 21. Not solved yet. Extension traits: adding methods to types you do not own
- 22. Not solved yet. Sealed traits: public to use, closed to implement
- 23. Traits with no methods: Copy, Sized, Send, Sync Read
- 24. #[derive] lies about its bounds Read
Check yourself
4 questions · one attempt eachThese do not count toward finishing the track. They are here to catch the things that are easy to read past.
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