4 ms·
Neat, I didn't know about the `async {}` feature. I think it's obvious that Rust chose `async fn` for familiarity with other languages. As you say `async` is j
by ridiculous_fish 5y ago
Neat, I didn't know about the `async {}` feature.
I think it's obvious that Rust chose `async fn` for familiarity with other languages. As you say `async` is just sugar on the return type, so logically it should decorate that type, not the fn keyword. "async fn" is even misleading since the function itself returns synchronously (and immediately): it's the returned value where the async-ness lies.
So I think Rust's use and placement of `async` is for familiarity, which traces back to C#'s original choice. Not to say that's a bad rationale.
Admittedly I didn't follow any of the Rust async design discussions so I could be completely wrong about all of it.
- Rusky 5y ago> "async fn" is even misleading since the function itself returns synchronously (and immediately): it's the returned value where the async-ness lies. You've got the causality backwards- it's the async-ness that causes it to return immediately. Async is primarily about the execution model of the entire function, and the return type is only changed in service of that model. The course of the design discussions started without async or await, using library-based Future combinators. Async was introduced as a way to desugar control flow and move knowledge of Futures into the compiler for borrow checking reasons, not out of any intention to mimic C#.
- ridiculous_fish 5y agoYou're quite correct, I hadn't thought of the fact that the transform and the return type were distinct. My mistake.