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.
Yeah, .await would remain the same. It's more so we could write this: http://s.map (|x| x * x); Rather than: http://s.map (async |x| x * x); For no reason other than "we have to write `async` here because it's an async closure".
-
-
What might help a little: the goal is to be allowed to pass sync closure bodies into functions that expect async. I think people will also be confused if they write “async” _without_ “await”.
-
The idea is basically an implicit lazy future? I like that!
End of conversation
New conversation -
-
-
tbh I'm still unsure why I have to write `move` when Fn vs FnMut is inferred
-
they're orthogonal, move is about whether the closure borrows or moves/copies its environment, Fn vs FnMut is about whether the closure is allowed to mutate its internal state.
- 13 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.