Tricks of the Trait: Enabling Ergonomic Extractors - Rob Ede

Rust's behavioural abstraction mechanism, the Trait, is a powerful tool for improving the ergonomics of the crates you use every day. In this talk, we'll explore some exciting applications of Traits in library code that cause your application's code to stay clean and concise. I'll start with a beginner's introduction to Traits, comparing and contrasting with similar ideas from other languages to get you up to speed. Then we'll look at a few examples from the standard library and common ways to incorporate trait bounds into generics/type parameters to clean up your code. Finally, we'll dive deeply into the "extractor pattern" used in the modern Rust web frameworks. At first glance, the extractor pattern can look like magic. However, we Rust users often shy away from things that are too magical because we care about retaining control. But this pattern should be easily understandable once we've peeled back the layers and seen how far Traits can be pushed in this way.

[@GlobalYoung7]

4:01 Traits Features 4:09 Abstracting Behaviour 5:13 Separate Implementation Blocks 6:58 Foreign Implementation 8:23 Default Implementation 9:09 Super-traits 10:48 Associated Types 11:35 Alternative Iterator Trait 13:11 Trait Bounds 15:16 Return-Position-Impl-Trait(RPIT) 17:31 Additional Reading 17:42 Extractors + Handlers 17:48 actix_web 20:12 pub fn to(handler: F) -> Route 21:03 trait FromRequest: Sized {} 22:14 Handler trait 25:45 pub(crate) fn handler_service(handler:F) -> BoxedHttpServiceFactory

[@fhools]

pretty great talk! gonna have to watch the last bit a few times for it to sink

[@mrpocock]

I find myself wanting opaque associated types, where the concrete type for the associated type in an implementation is not visible outside of the declaration scope.

[@phenanrithe]

Thanks for the talk! The orphan rule is a major problem in Rust, I think it should be relaxed for the local crate and as long as it's not public. How many times has it forbidden using an external type with an external trait required in a bound? The resolution, if this trait were to be added later, is simple: the definition of the current crate prevails, to avoid any sudden change of behaviour. Besides, that's what non-regression tests are for, one should test their crates on each new version of the compiler, since it's not always 100% back-compatible.

[@SimonBuchanNz]

There might be some more relaxation possible, but the issues are harsher than you might expect. Firstly, impls (currently) don't have accessibility, so there's no way for the orphan rule to apply if "it's not public". (Adding crate private impls might be an option, but that would need a lot of design, there's more to think about than you might guess) But really, the reason the orphan rule exists isn't for direct upstream crates adding a conflicting impl, but a diamond dependency situation: in the general form you're A, and you depend on B and C, which both depend on D and E (one or both of which could be std). Now imagine that D has a type, and E has a trait, and that B and C both provide an impl for them. Now *you*, as crate A, get broken, because only one impl can exist for a type and trait, despite B and C not knowing about each other. Loosening the orphan rule requires finding a way to prevent it from allowing this general issue to be hit, even if in your specific use it wouldn't be. Previous loosenings have exploited that the std library can promise it won't add an impl to the language, or manages to squeeze a generic type taking a local type as a parameter through as effectively a local type (though the actual rules are a bit stricter)