@WG-async-foundations meeting time
ok, let's start with triage
only one today
this is something I'd categorize as an "enhancement"
well, it's sort of a bug, but one that's fairly easy to work around
I guess without good diagnostics it can be a pain though
I'll tag it OnDeck
Does this feed into trying to keep the futures having minimum space in memory?
yes, but the main concern of mine for now is confusing compiler errors
I think that's a reasonable stance to take, I think it's currently the biggest QOL issue
ok - so next thing on that issue would be an example of what we'd like the error to say?
either that, or we just don't emit an error in those cases
the bug is about cases where we've already moved a type out of the generator prior to the yield
we can detect that, and not include it in the GeneratorWitness (iirc)
I'm all for that - that would mean smaller futures.
I'll leave a comment about it
okay, moving on
we closed some of these in the last week
some are still ongoing
@Aaron Hill have you been able to make progress here?
looks like there are more recent comments on the PR
(back in cache.. this was something we couldn't agree on how to fix, so that's what the work is blocked on)
but it doesn't look like we've come to any consensus on
maybe @Aaron Hill and @nikomatsakis should schedule some time to chat
okay, this seems to need a refactor of the type checking code for generators
(well, not a pure refactor per se, we'd change the behavior)
and it seems like there's a "direction of exploration" that niko makes clear.. but it's still a bit open ended
I guess I'm wondering if @nikomatsakis should stay assigned, or if they've already done all the investigation here
I'll leave a comment, I guess
:wave: -- sorry, I was actually at a dr app't until recently, back now
(took longer than anticipated, not sure how much I'll be able to be online today)
anyway re: #67651 I hope to do a bit more investigation there
okay, good to know
for #67611, I left some ideas but the conversation doesn't seem to be gaining any traction :)
yeah that's a tricky one
I read @Matthew Jasper's comment -- I guess I'm not 100% sure what I think yet, I have to re-read the MIR changes
okay, well I guess we'll discuss it more outside the meeting
I think this is probably a dup of #67651
should we close or leave open?
if you're investigating more, I guess we can leave it open until we're sure
leave open I think
I think this is fairly blocked :/
I wonder if it might be someting to consider for deeper discussion at Rust All Hands... it's certianly on a list of like "technically complex issues to resolve"
not sure tbqh if Ruts All Hands is a good time to dive into such issues :)
if not then, then this is more support for having a regular "design" meeting :)
it seems like there are a number of things blocked on design aspects
Hmm, I'm not so sure
What are you thinking of?
I guess it depends on how far out you zoom
and what kind of design you're talking about :)
All-hands is definitely a good place to kick complex issues off
I mean, all the open Focus issues :)
(maybe my definition of design is different)
I see, I guess it depends on how blocked
I guess I just mean that #57017 just seems "a step up" in complexity
compared to the others
yeah, fair enough
but I do have to spend some time on #67765
I guess I'm saying that we should have time to dig into some of the context around the rest of the issues
and spread that context around a bit
anyways, we haven't gotten to the OnDeck issues yet
is anyone looking for things to do?
seems like not everyone is around today, so I guess we'll call it
as always, if anyone wants to pick up something asynchronously, the OnDeck list is a good place to start :)
thanks for coming, y'all