Hey! Just tried to ask on IRC and got redirected to here. @nikomatsakis , I just read your post on async-await stabilization, and wonder: how would you be able to stabilize async-await without the futures API RFC being even merged?
@Léo Gaspard Here is a new "topic" for you to have this discussion on.
@nagisa Thanks! I don't get zulip's UI yet, guess I'll just wait for somewhere on the screen to display an answer, then try to reply, and then happily go back to IRC :°
Zulip is very good!
To answer your question, ~technically~
? exists without the
Try the related machinery being stable as well
So I would imagine it being possible to do the same for
Implementing something useful that could use the keyword would still involve nightly code, the same way implementing a
I guess zulip is very good, but it's a system none of the groups I'm active in uses, it's a brand new UI with brand new concepts, and I don't particularly love the UI or idea at first sight, so it's an effort I'm not willing to make for now :)
(edit: oh and it looks like threads aren't nest-able, tried to answer just your “Zulip is very good!” comment and failed to)
it's an effort I'm not willing to make for now :slight_smile:
? exists because there's a useful implementer of
Try in libstd:
Result. AFAICT there'd be no useful implementer of
std, and writing stable code that's forced to use nightly-only libraries isn't really interesting, is it?
I don't really get what stabilizing it right now gets us compared to just keeping the feature gate for now, if the code has to be nightly anyway
Perhaps stabilising indeed does not provide anything much at the moment, as you cannot do anything with the
Future that’s in the stdlib without a nightly compiler.
However, do keep in mind that
async fn does not necessarily expose to the end user that the function has the return type of
Future, or that exposition can stay unstable without interfering with the basic
await that_fn(...) use-scenario.
In general my personal feeling is that
await won’t be stabilised any time soon either way
This could be seen as very similar to
fn foo<F: Fn(...) -> T> being stable but
fn foo<F: Fn<(...), Output=T> being unstable :slight_smile:
http://smallcultfollowing.com/babysteps/blog/2019/03/01/async-await-status-report/ appeared to point out that
await was going to be stabilized soon, actually, which is exactly what triggered my inquiry
Heh, we haven’t even decided if
await should go in prefix or postfix the expression, to the best of my knowledge.
Heh, if I read correctly, the point of this article is “just let's do like
try!and have a regular
await!() macro and see later”, which… given I seem to understand that it wouldn't even be possible to actually use it stably yet, sounds to me like a bad idea to have stabilized. Now, maybe I have missed @nikomatsakis 's point :)
Yeah, as the post points out there are multiple unresolved questions which is why a workgroup specifically for that has been created.
I could see
async!() being stabilised sooner.
(FYI: I've moved the original question to this topic)
@davidtwco black magic!
If we can stabilize a usable subset of async that would be a great upgrade from where things are today. Personally I'm ok with async! macro format as it hints there's magic under the covers. The biggest question I have is what can I do to help... Ah I see I should be reading here:https://rust-lang.zulipchat.com/#narrow/stream/187312-t-compiler.2Fwg-async-await
@Giles Cope The question is what exactly would be stabilized: if the
Futures API RFC is not stabilized (and as it's not even merged yet it can't be stabilized), then a stable subset of async wouldn't be useful for anything that I know of
I see your point, they are pretty intertwined. I was assuming that this push would be to get futures into a mvp shippable state as well as async. Async without futures would have no future? ;-)