Attendance: TC, eholk, yosh, CE, tmandry, Daria Sukhonina
Minutes: TC
This meeting's issue:
https://github.com/rust-lang/wg-async/issues/331
https://github.com/orgs/rust-lang/projects/28
https://hackmd.io/HKBIGY5nSPuhyrcCe0TOHA
TC: We were close last week. What were we close on?
tmandry: I started writing it down. There are the things we want to ship, then there are the things that we want to work on.
In terms of what we want to ship:
Things we want to work on:
eholk: That sounds generally good. I think async closures would be powerful; I've been seeing that in the last week or two during experiments.
eholk: RTN would be good also. I hope we can get that also. The lang design meeting yesterday was interesting. There are internal users I know of that have hit the problems solved by this.
eholk: For AsyncIterator, it feels like this is close enough we should be able to ship it.
eholk: We should also work on async Drop. And design principles are good also. We should also think about documentation or things like tools to help control future sizes. I'm not sure we're the best group to do it. But if not, we should maybe take down the async book. In its current state, it's not a great resource.
tmandry: +1 on taking it down or making it a good resource, or at least putting a banner on it pointing to better resources.
TC: +1 on putting a banner on it.
yosh: +1 on putting a banner on it.
yosh: Overall, the list looks right to me. The way I'm looking at this, it's not just for ourselves, but how we'll communicate it publicly. The first set of things are the things we're more confident about. It's about setting expectations. The expectations for the first set are reasonable. The three latter items have more questions.
TC: …quesion on async generator closures to CE.
CE: On the lang design meeting for RTN, I have some concern about what was proposed for the MVP.
CE: On async generator iterator closures, those are blocked on either the new solver or on introducing three new traits for LendingFn*. I wouldn't want to do the async gen closures without working out the trait hierarchy for LendingFn*.
TC: It would be worth experimenting.
CE: We landed AsyncFn instead of using LendingFn at this point.
eholk: What's the timeline on the new solver?
CE: It's years.
TC: So with the new solver, how does that affect the LendingFn traits we'd need?
CE: We'd need two traits rather than three.
tmandry: What's the plan on AsyncFn?
CE: We have two choices. We can either stabilize AsyncFn, or we can add sugar for async Fn() -> ... We can always go back and do the former later. But doing it via sugar leaves more doors open.
yosh: This is also why I'm worried about the interaction with async Drop.
tmandry: The sugared version makes sense to me.
eholk: I like the sugared approach a lot.
TC: +1.
tmandry: There has been much discussion on AsyncIterator. It could seem a bit unsatifying, given all that discussion, to say that we're not going to stabilize something here. It might be better to say that we want to settle the design questions this year and ship it early next year.
TC: It'd be good to pin down the degree to which we actually do or do not have clarity. There seems disagreement even on that point. In recent discussions, I've been trying to build clarity on that.
tmandry: +1. There's the poll_next question, and there is the question poll_pending question.
TC: +1 on poll_pending being a major design point.
yosh: The interaction between async Drop and the AsyncIterator trait specifically, but this applies generally to all async traits.
yosh: Specifically, I'm concerned about stabilizing AsyncX trait interfaces. I'm less concerned about AsyncFn if we only stabilize it through sugar rather than stabilizing the trait.
eholk: In talking with Yosh, I understand that he's open to later migration in the ecosystem, but he doesn't want to see migration costs imposed when it's stabilized in the standard library.
tmandry: I'm trying to understand, what's the potential interaction between async Drop and the async traits.
yosh: Let's defer that to the meeting next week.
TC: OK, so high level point, we need to nail down to what degree async Drop does or does not affect or block our other plans for stabilizing async things.
TC: What do we think about this item?
yosh: I feel like we have clarity among a small group. But we need to sharpen this down and have everyone understand it. There is some dependence on the new trait solver here.
TC: My feeling is that this item has more implication on the stabilization of AsyncX things than async Drop, though perhaps the two are a bit tied together.
yosh: +1, that's probably right.
tmandry: We should maybe think about what the deliverables are for the items on our list.
TC: Perhaps we should describe the items in terms of the problems we're trying to solve.
tmandry: +1 on that.
eholk: If we know the specific solution, we should probably say that. But if it's not clear or there's ambiguity, it becomes harder to trust the roadmap.
TC: +1, that's a good point.
tmandry; Framing in terms of problems we want to solve rather than in terms of solution is something I don't have a strong feeling on. But we should say how far we're going to solve the problem at least.
yosh: Perhaps we should communicate this in terms of finishing what we started.
tmandry: I propose we start an outline of the blog post.
Daria: working on a design around linear types that allows scoped threads. Idea is to add a Leak trait so we can have scoped task handles that await in async Drop.
Daria: see https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/The.20destruction.20guarantee.20and.20linear.20types.20formulation/near/417214626. Blog post would be good to read before next week's async Drop meeting.
TC: Here's a sketch of ordering:
We start by talking about the problems we've been focused on, and discuss the big things we've done to address them recently, most notably RPTIIT/AFIT. Then we talk about the residue left from that and how we've addressed that with trait-variant which will then lead into the further work we're doing to address AFIDT using the trait transformer pattern in trait-variant.
The discussion of trait transformers leads into discussion of the problem that RTN solves and the realm of solutions there.
From there, we talk about the further problems that async closures address and the work going forward there.
Then we talk about the problems that underlie the things that we plan to work on this year, including async Drop, async iterators (and async iterator closures), and maybe async.
Then we close with a discussion about design principles.
What do people think about that plot arch?
tmandry: It's important to keep the blog post relatively short, so talking about the problems that underlie some of this work could make the post long.
eholk: We could link to outside posts on these problems to keep things concise.
TC: Agreed, we'd summarize the problem then link to more full resources.
yosh: We should think about what is the purpose of this post? Who are we communicating to?
TC: To ourselves, to the rest of the project, and to everyone else.
tmandry: I agree it's to all three of those.
tmandry: Let's nail down the async deliverables.
Consensus sketch:
Send bound problem for the purpose of solving to the middleware pattern and for adding bounds to RPITIT return types generally."trait-variant, or some solution to AFIDT in the ecosystem.
async gen in nightly.
for await syntax.AsyncIterator trait.
(The meeting ended here.)
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe