4 ms·

> If you ... look at questions surrounding the core principles of Rust—e.g. ... ‘why does Rust’s async implementation require boxing so often?’—you’ll soon find

> If you ... look at questions surrounding the core principles of Rust—e.g. ... ‘why does Rust’s async implementation require boxing so often?’—you’ll soon find that a lot of these restrictions are a natural consequences of the design of the language I do find that satisfying, that "There is a reason for these restrictions" feeling. But, I can't remember the last time I boxed an async future. Maybe because I almost never use recursion. I'd like to see some of the author's code to see where boxing is used.

indiv0 4y ago
Because there’s no async fn on traits yet, almost all “async” traits are returning Pin<Box<dyn Future<Output=T>>> under the hood. Same principle also applies if you’re trying to put a future in a struct (to create a named future). One of the fields will have more or less that type. This is useful for a few reasons (e.g. making it easy to refer to a specific future in type signatures or for writing futures out by hand).
- deleted 4y ago
  [deleted]