I think the ideal world we would make the async API be usable from non async scopes without using a reactor (probably with some duplicated APIs for sync and path desugaring tomfoolery) but I don't know if that would be worth the effort.
-
-
Replying to @ekuber @yoshuawuyts
It's only async if it's from the .await region of std, otherwise it's just sync.
2 replies 3 retweets 11 likes -
-
Replying to @ekuber @yoshuawuyts
I try!(). but actually how cool would that be if by slapping .await on it, it used an async version
1 reply 0 retweets 5 likes -
A bit too magical for my taste. But I’m an anti magic fanatic
1 reply 0 retweets 3 likes -
It's a trade-off. Magic is nice when you don't notice it but very anoying when you do and it doesn't do what you wanted it to do.
1 reply 0 retweets 2 likes -
Replying to @ekuber @heinz_gies and
I worry that it would just make errors harder to understand.
1 reply 0 retweets 2 likes -
Replying to @ekuber @heinz_gies and
But it would certainly be *nice* ergonomics.
1 reply 0 retweets 2 likes -
Replying to @ekuber @heinz_gies and
Thinking about it further, there's nothing stopping us from saying "hey pal! You're in a sync block but using an async method. Wrap it in async and await or use this equivalent sync method!"
3 replies 0 retweets 4 likes -
Replying to @ekuber @heinz_gies and
We already do that for the incorrect usize::MAX
std::usize::MAX1 reply 0 retweets 3 likes
Fwiw I think there are legit uses for mixing sync/async code, and probably would always want to keep the async/await syntax (next blog post!!) Though very into the idea of thinking of how we can improve ergonomics along the lines which you've been describing — err messages deff!
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.