So @Taylor Cramer what I was saying in the call was that I feel like, from the impl POV, I'd feel better if we had a "plan" for how we were going to maintain the feature and fix the bugs. I'm a bit nervous about stabilizing and then having to scramble to fix bugs that are now exposed to stable code
It seems to me like this was a big hole in our planning at the all hands, in that this is a major feature effort that you've been carrying solo and sort of flew under my radar :(
(Which is to your credit that I've not had to notice it very much -- well you + @Zoxc, since it's mostly desugaring to generators)
@nikomatsakis Is there a "plan" similar to what you have in mind that we've had for previous features?
(asking because I think it'd be helpful for getting an idea of what sort of thing you have in mind)
IMO previously it has felt more comfortable because the person who implemented the feature probably wouldn't have had as high of latency in fixing bugs as I have at the moment...
@Taylor Cramer Not necessarily. I don't really mean a "plan" as a written document per se, mostly that we feel like we know how we plan to address the outstanding bugs and feel comfortable about it.
But also we've traditionally been not very good at this
We said during the triage that there were kind of two categories of bugs: those where we sort of have no idea what is going on, and those where we have a vague plan to fix
Particularly around the lifetime issues it seems like that plan is maybe a bit too vague
I guess it'd be good to dig into those issues that are a bit unknown and see if we can diagnose some of their causes
@nikomatsakis yeah, the biggest thing that worries me about the lifetimes issue is that the only plan I have that starts looking like a "correct" implementation would basically re-implement lifetime elision during lowering
OK. I'm trying to decide a bit what to do with myself this afternoon. Feeling kind of drained from a long week. Maybe I'll dig into some of those bugs a bit, particularly the weird ICE-y ones
and/or put a bit of thought into this
One thing that is a bit unknown for me: do we think maybe we want to try to make a more "native" implementation?
I'm not 100% sure what that means, but I feel like it's been tossed about a few times
Is it just a matter of error messages?
@Taylor Cramer maybe we should make an async-await stream..?
I'm not sure I know what a more "native" implementation would look like
"Native" to me sounds like "touches more parts of the compiler after lowering"
I'm also not sure. I feel like the current, generator-based lowering feels a lot like what we want -- the main thing is probably the macro that expands to
yield being a problem
i.e., if we had a keyword, we could leave some span hints and things so that we know to customize error messages
I guess one case might have to do with the error message around the return type hints and so forth, but I feel like we can still thread that info through by lowering in careful ways, or other small tweaks
as an aside, I'm thinking we should make a stream for async-await, at minimum, and I'd actually like to try and do a "real" working group -- meaning basically that we establish a meeting time, and try to start drawing up a plan for the remaining issues etc, and kind of reach out to some people to help.
Given the state of the impl, maybe we don't want to reach out to totally new hackers, but I bet some "journeypeople" like @davidtwco, @Santiago Pastorino, or others might be interested.
I'm not really clear on what process we should/would use for "new working groups" =) but I feel like this is obviously something that we as a project are trying to ship so it makes sense.
Let me just rope in @T-compiler I guess -- I'm discussing here that I think we want to have an "async-await working group", focused on the work needed to ship the
async fn feature. This work has heretofore been done primarily by @Taylor Cramer but it feels like a clear objective, one that we just kind of overlooked in the list.
Seeing as we're still in this primordial phase, I don't have a clear picture on how to "request" to start a WG -- is there any objection to me "creating" the WG (i.e., making a template, making a Zulip stream, etc)?
Re: diagnostics, the await macro could be turned into an intrinsic which would buy you as much control as having the stabilized keyword.
It'd be a good idea to do so regardless because the only thing that would have to change once the syntax dust settles would be the parser.
I also think that the issues around
yield will disappear quickly when we decide on an
await-keyword-based syntax and implement it, and I think the desugaring to
yield should be relatively easy to hide from the user
just as the desugaring of
? to a
match is fairly transparent
I'm much more concerned about the implementation and diagnostics around the lifetime issues
OK, so nobody raised any objections
@Taylor Cramer shall we schedule some time to develop an async-await impl problem roadmap? I would like to kind of place the bugs that we found in that triage in an order and maybe dig into the them .. I imagine the lifetime limitations are sort of top priority, so we could probably do the "Pre-triage" here in Zulip and use a call to really dig into the details?
@nikomatsakis sure, I'd be happy to meet again to talk through the impl schedule
Although I think I'd actually put the drop-order-of-arguments stuff above the lifetime issues in terms of priority
since that's a more serious backcompat hazard, I think
@Taylor Cramer indeed, though it seems .. well, I guess there's probably some impl questions there, in terms of how to achieve whatever it is that we want, but I'd like to first know what we think we want
I have a meta question on that point actually
can you think of
async fn in terms of a desugaring to async blocks?
(In general, my personal preference for these sorts of questions is to establish a definite desugaring, and try to answer questions of the semantics in terms of that desugaring)
OK, I created a calendar event for an investigation of various issues tomorrow. We should probably decide which ones to dig into =)