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.
-
Show this thread
-
E.g. in regular closures you can often add `move` to change semantic meaning: foo(|x| x * x); // borrows foo(move |x| x * x); // takes ownership But `async` would never be optional: foo(async |x| x * x); foo(|x| x * x); // compile error So why not infer?
4 replies 0 retweets 2 likesShow this thread -
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?
1 reply 0 retweets 1 likeShow this thread -
Usual disclosure: I'm not on the lang team, nor am I a language designer so please interpret this accordingly (:
3 replies 0 retweets 0 likesShow this thread -
Replying to @yoshuawuyts @Argorak
I will just point out that syntax isn't only there for the compiler, so syntax that is redundant to the compiler can still be useful to the humans.
1 reply 0 retweets 1 like -
I don't know enough about the way people think about and use async to know what the solution to this tradeoff is, only that the tradeoff itself is worth considering.
1 reply 0 retweets 1 like
Fully agree with what you're saying.
-
-
Replying to @yoshuawuyts @Argorak
We like to think about when computers let is not write things but we often don't think about when computers can write things for us. For example, what if some tool could insert the async keyword where it belongs automatically?
0 replies 0 retweets 4 likesThanks. 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.