Hey @WG-async-foundations =)
So last week we were doing some triage and discussion about "async-await is stable, now what?"
I don't see any fresh uncategorized issues
but there are two blocking issues
one of which I had not seen before
but it looks like @Matthew Jasper has a fix (https://github.com/rust-lang/rust/pull/64038)
OK, so, we discussed this in the lang team meeting and @Taylor Cramer was going to leave a comment but I guess they didn't get around to it
the tl;dr was that we decided to align the sync/async semantics
@davidtwco you're assigned to this one -- we think that changing the desugaring will suffice (per @Matthew Jasper's suggestion), did you want to give that a try?
Unfortunately, I've not had an opportunity to work on this yet (work is very busy right now, there's a milestone at the end of the week). I intend to look at it this week though.
If you'd prefer, we could find someone else
If you're too busy, that is
I should be able to do it.
there is one other issue currently marked as "blocking", though it's a "soft" sort of blocking
async fns incorrectly #63710
It seems like the problem here lies in rustdoc's split, whereby local crates are documented from the AST
but foreign crates come from metadata
and hence foreign crates are seeing the desugared version
this seems like a fairly big "gotcha" especially for facade-like patterns
I guess the obvious fix is to encode some info that the function was originally an "async fn", perhaps -- more generally -- a "original signature" sort of data
although @Esteban Küber proposes another direction:
Should we also consider always documenting
Fn() -> impl Future<Output=_>as
async Fn() -> _?
not sure what I think about that
"maybe" I guess :)
fwiw I think _that_ is also somewhat hard so it might be best to encode the asyncness in metadata in some way
yeah I was thinking the same thing
I personally don't see this as all that blocking though. I can probably allocate some time to investigate this week, though, fwiw
I don't think it's blocking -- it's more of a "nice to have"
(it's tagged as -Blocking and -Unclear, which is why I ask :)
essentially, looking for things we can do to improve people's first impressions of async-await
heh well yeah I abused the tags
which brings me to the last topic -- last week we did a triage where we started going through all the "deferred" issues, looking for things to try and address sooner rather than later, and just to get a feel for what they were and maybe hints for how to label them in the future
we made it about 50% of the way
One thing we identified is that we may want
#[inline] to be an error (though I see in the doc that @centril maybe doesn't agree). In short because it's not really clear what it should mean, and right now it doesn't do much.
(On a related note, we may want to mark all async fn "constructors" as
but the most important diagnostic issue we identified was trying to improve our error messages when a future is not
Send -- right now you get this error late, at the point of use, but often we could localize it effectively to the future definition (i.e., we have enough data available)
maybe I'll open some issues to track those
is anybody who is present interested in this diagnostic issue in particular? I think I could try to leave some notes as to how to go about it, though it would take a bit of time for me to think about
also, we should I guess spend some time going over the rest of the issues
this is an example of a diagnostic fail, incidentally :)
I marked it as blocking, I'll assign to myself to try and leave some mentoring notes
It's not really blocking :)
OK, well, I guess that's it for now. I think we should do another session to finish up the remaining 50% of those issues -- later this week I guess?
doodle poll part 2?
PS @Giles Cope maybe we'll bump https://github.com/rust-lang/rust/issues/63167 to "blocking" (just so we're tracking it)?
One thing we identified is that we may want #[inline] to be an error (though I see in the doc that @centril maybe doesn't agree). In short because it's not really clear what it should mean, and right now it doesn't do much.
I do disagree;
#[inline] is a hint and it 1) doesn't have to do anything at all, 2) can have its meaning changed whenever we want
but I think we should not introduce contextual static semantics for it
(Note: moved some comments about whether #[inline] on async fn should be an error to this topic)