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.
-
-
In a way this is how blocks already behave; they already apply inference: async fn foo() { { /* this block supports .await */ } } Which is different from "async blocks" which are a construct to create a *new* future (value). Does that make sense?
Show this thread -
Usual disclosure: I'm not on the lang team, nor am I a language designer so please interpret this accordingly (:
Show this thread
End of conversation
New conversation -
-
-
would `.await` still be explicit? the thing I value in async/await JS code is that points where the code can be interrupted are clear but in a language with threads, you can interrupt anywhere so there distinction is not so important
-
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".
- 2 more replies
New conversation -
-
-
Personal opinion on that: making ‘async’ optional and inferring it is too magic. With move vs. no move, the keyword switches behaviour so it’s not inferring either.
-
Well, it’s the point that move is necessary because of ambiguity, but async to my reading not (because the closure will contain an .await). This actually unlocks some interface uniformity, so it’s not too keep shorter or so.
- 7 more replies
New conversation -
-
-
Yeah inferring it makes sense in this case
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.