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.
Usual disclosure: I'm not on the lang team, nor am I a language designer so please interpret this accordingly (:
-
-
This would probably open up a number of weird corner cases. E.g. what if a closure is used as both sync & async? What if the surroundings change so that an async closure becomes sync? Would the error messages point to the right span?
-
I think you're asking the right questions. Especially the first one: my guess is that would "just break" and say it can't infer the right one for both cases -- e.g. pick one. But how to teach the inference engine that? Good q; might not be worth it.
- 1 more reply
New conversation -
-
-
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.
-
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.
- 2 more replies
New conversation -
-
-
It's easy to forget that, based on the stuff you write and the work that you do
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.