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.
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.
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)
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
pretty great talk! gonna have to watch the last bit a few times for it to sink
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.
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.
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)