Jon kindly reached out and let us know of some good news! The RFC for the new capture rules for the 2024 edition has now been accepted! rust-lang.github.io/rfcs/3498-lifetime-capture-rules-2024.html
A slight nitpick for 15:00 (argument impl Trait): This can still be viewed as an example of an existential type because (exists a. a) -> b is the same as forall a. a -> b (using haskell notation). If you represents exists with a dependent pair this can be viewed as dependent currying: (a: Type, a) -> b same as (a : Type) -> a -> b. So imo return and argument position impl Trait are consistent.
Jon is a great teacher. I wonder if I have some kind of eye cancer or if he has it😬. Gray code on purple background is among the hardest to read I have encountered so far.
@22:30 It's a little odd to me that we don't just that it behaves like a return position impl trait-i.e., that there must be some single type which satisfies this that the compiler knows but you're not explicitly specifying. Like, the argument to eat is not "an impl Trait type", it's just an associated type for the trait-which must be a single, specific type-which happens to be defined opaquely. Thus, the function just knows that it's some kind of Iterator and so that's all you can do with it in eat.
From the public viewpoint, that's correct, but in the function implementation, you may want to call functions on your specific known type. For instance, the real hidden type returned in the "into_iter" method could also implement DoubleEndedIterator for Odd's ExcessiveIntoIterator trait implementation. Because you are guaranteed the type returned from into_iter() is the same exact type passed into eat, you can now use DoubleEndedIterator in eat(). This does not require that other trait implementations would need to implement DoubleEndedIterator. If you did not care about that eat() is using the same exact type returned from into_iter(), you could of course, use a generic or non-associated impl Trait parameter instead.
For lifetimes I think Rust would be well served by separating lifetimes from types, like Ocaml did. That is, the lifetime should not be part of the type of a variable like it is now, which forces invasive code changes when a lifetime specification is added.
I don't understand the need for a single defining use with #[defines]. Wouldn't all uses need to be compatible, so any one could be taken as the defining use?
Only at the source level. When actually compiling the hidden type determines things like the size, trait implementation function addresses, etc. Essentially the difference between static and dynamic polymorphism (impl and dyn)
@@SimonBuchanNz The hidden type matters, yes. The point is that for there to exist a defining use it has to actually define a single type that fits. If two potential defining uses disagree it should be a compiler error, and if they don't then we can use that type.
I think the issue is once you start getting inference. You can easily set up a situation where the type of one integer affects the type of another, which might not be intended. You might be able to set this up in a way where this works in both directions to give different results. Still, it seems to me like this could be handled by allowing multiple defining uses *if they agree* and instead allow a use to opt out of being defining.
Jon kindly reached out and let us know of some good news!
The RFC for the new capture rules for the 2024 edition has now been accepted!
rust-lang.github.io/rfcs/3498-lifetime-capture-rules-2024.html
Every Jon Gjengset lecture is a wonderful new experience! Thanks for uploading! 🥰
A phenomenal educator, my Rust and even general CS skills have grown immensely since discovering Jon
I'd just like to say thank you for the `Captures` trick. Today was the second time I've come back to this video to use it solve my lifetime issues.
I love that Rust keeps having embedded users in mind. I think it’s by far the best area for Rust to shine, even if it’s not a popular one.
I wish RustRover had embedded developers in mind, also.
@@meowsqueak ha ha ha. i switched to zed and now I am happy though features are still lacking for iot.
A slight nitpick for 15:00 (argument impl Trait):
This can still be viewed as an example of an existential type because (exists a. a) -> b is the same as forall a. a -> b (using haskell notation).
If you represents exists with a dependent pair this can be viewed as dependent currying: (a: Type, a) -> b same as (a : Type) -> a -> b.
So imo return and argument position impl Trait are consistent.
Jon is a great teacher.
I wonder if I have some kind of eye cancer or if he has it😬. Gray code on purple background is among the hardest to read I have encountered so far.
7:45 That compiler gets to peek into `impl Trait` at return position to discovered Send + Unpin seems like a mistake, however expedient.
Rust is blazing as fast as possible the path to being as complex as C++
at least in c++ you can still choose to not.
@22:30 It's a little odd to me that we don't just that it behaves like a return position impl trait-i.e., that there must be some single type which satisfies this that the compiler knows but you're not explicitly specifying. Like, the argument to eat is not "an impl Trait type", it's just an associated type for the trait-which must be a single, specific type-which happens to be defined opaquely. Thus, the function just knows that it's some kind of Iterator and so that's all you can do with it in eat.
From the public viewpoint, that's correct, but in the function implementation, you may want to call functions on your specific known type. For instance, the real hidden type returned in the "into_iter" method could also implement DoubleEndedIterator for Odd's ExcessiveIntoIterator trait implementation. Because you are guaranteed the type returned from into_iter() is the same exact type passed into eat, you can now use DoubleEndedIterator in eat(). This does not require that other trait implementations would need to implement DoubleEndedIterator. If you did not care about that eat() is using the same exact type returned from into_iter(), you could of course, use a generic or non-associated impl Trait parameter instead.
This guy is a singleton type.
For lifetimes I think Rust would be well served by separating lifetimes from types, like Ocaml did. That is, the lifetime should not be part of the type of a variable like it is now, which forces invasive code changes when a lifetime specification is added.
Thank you
Amazing talk
I don't understand the need for a single defining use with #[defines]. Wouldn't all uses need to be compatible, so any one could be taken as the defining use?
Only at the source level. When actually compiling the hidden type determines things like the size, trait implementation function addresses, etc.
Essentially the difference between static and dynamic polymorphism (impl and dyn)
@@SimonBuchanNz The hidden type matters, yes. The point is that for there to exist a defining use it has to actually define a single type that fits. If two potential defining uses disagree it should be a compiler error, and if they don't then we can use that type.
I think the issue is once you start getting inference. You can easily set up a situation where the type of one integer affects the type of another, which might not be intended.
You might be able to set this up in a way where this works in both directions to give different results.
Still, it seems to me like this could be handled by allowing multiple defining uses *if they agree* and instead allow a use to opt out of being defining.
Where’s the slides?
From Jon's twitter: jon.thesquareplanet.com/slides/impl-trait/