Async from scratch 3: Pinned against the wall

https://news.ycombinator.com/rss Hits: 7
Summary

So, we've covered polling. We've tackled sleeping (and waking). Going back to the definition, that leaves us with one core concept left to conquer: pinning! But before we get there, there was that one tiny other aside I'd like to go over, just so we can actually use the real trait this time. It'll be quick, I promise. And then we'll be back to what you came here for. Intermission: Letting our types associate Let's ignore poll() completely for a second, and focus on another sneaky change I pulled between Future and SimpleFuture: trait Future { type Output; } trait SimpleFuture<Output> {} What's the difference between these? Future::Output is an "associated type". Associated types are very similar to trait generics, but they aren't used to pick the right trait implementation. The way I tend to think of this is that if we think of our type as a kind-of-a-function, then generics would be the arguments, while its associated types would be the return value(s). We can define our trait implementations for any combination of generics, but for a given set of base type, each associated type must resolve to exactly one real type. For example, this is perfectly fine: struct MyFuture; impl SimpleFuture<u64> for MyFuture {} impl SimpleFuture<u32> for MyFuture {} Or this blanket implementation: struct MyFuture; impl<T> SimpleFuture<T> for MyFuture {} But this isn't, because the implementations conflict with each other: struct MyFuture; impl Future for MyFuture { type Output = u64; } impl Future for MyFuture { type Output = u32; } error[E0119]: conflicting implementations of trait `Future` for type `MyFuture` --> src/main.rs:13:1 | 10 | impl Future for MyFuture { | ------------------------ first implementation here ... 13 | impl Future for MyFuture { | ^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `MyFuture` For more information about this error, try `rustc --explain E0119`. error: could not compile `cargo0OpMSm` (bin "cargo0OpMSm") due to 1 previous error We're also not a...

First seen: 2025-05-22 21:27

Last seen: 2025-05-23 03:28