Stray thought that came up in conversations with @Argorak the other day: what if async closures didn't need the `async` keyword?
The trait would still be AsyncFn (or similar), and that'd be the marker for whether it's an async closure. Unlike `move`, `async` is never optional.
When passing a closure, and it's expected to take AsyncFn, *also* having to prefix the closure with `async ||` provides no extra value. It's often useful to add `move` to closures on the fly, changing semantics. That doesn't seem to be the case for async closures.
-
-
Idk, I see value in it being explicit of what is happening. Same as with unsafe to me it is about being explicit when it comes to tradeoffs. unsafe is for safety, async is for performance. A closure that happens to be end on a scheduler can have harsh performance impact.
-
For example, if the outer function changes it’s signature and goes from synchronous to asynchronous those things could change under your feet without any knowledge, and that’ll probably be a fun debugging session. With forcing ‘async’ a user is made aware of the change instantly.
- 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.