# Open discussion: Mar 23, 2023

This is the doc for open discussion within wg-async about various design questions and other topics. Please feel free to propose a topic below.

On the day of the meeting, we'll do a quick poll to sort the topics by interest and then go through them one by one. If you have a brief (under 5 min) introduction prepared for the group, we'll take that into account as we prioritize the topics.

###### tags: `open-discussion`

Leave discussion topics below.

---

## Update 2023 timeline

tmandry: Let's check the items in the [2023 roadmap](https://github.com/orgs/rust-lang/projects/28/views/2) and update them. Let's make sure we're on track to ship AFIT this year.

---

## async keyword for Send bounds

tmandry: I think `async(Send)` only makes sense if we require `async` keyword for traits with AFIT in them.

yosh: Agree, I like trait transformers.

eholk: Want to caution that these are new ideas before we commit.

eholk: Benefit of `async(Send)` is that it's a smaller feature, therefore has less risk of unwanted ramifications. Lower complexity / lower benefit.

yosh: In trait transformers, can any trait be used or only auto traits?

eholk: My understanding is we have built-in transforms, defined for different things like auto traits, but kind of one-off. Could have a general mechanism for any transform, but adds a whole level of complexity. Could be Send-ifier, async-ifier, dyn-ifier.

---

## Effects

yosh: These are all effects ^. Try, async, .... Auto traits are one that we have in the language. Composition of them is a class of problem.

If Send is an effect are the other auto traits also effects? I think yes. Exclude UnwindSafe because not used. Send, Unpin, Sized (not an auto trait but like one).

I'm partial to trait transformers because it feels like it addresses this fundamental problem. I think if we follow that thread we'll get a better dyn system too.

tmandry: Seems like auto traits describe the underlying types in your struct. Async has more to do with behavior. Might be useful way of categorizing these.

yosh: Because of the way auto traits propagate we can't have a "positive bound", e.g. a `Send Fn` that promises its return type will be sendable.

yosh: From a consistency perspective, should we also include `async` as an effect-like keyword? Why or why not?

* Negative bounds

tmandry: I'm observing consistency that `Send Trait` and `async Fn` are both shorthand for approximations of what you might want. There might be lower-level controls you might want to use also.

---

## 2024 goals

tmandry: Let's work backwards from 2024 goals and fill in missing roadmap items. We'll also discuss the question of iterators versus portability in 2024.

If we're feeling ambitious, maybe we can tackle the 2027 items next.

eholk: Should someone else do generators?

tmandry: I think of it as an initiative. Could be driven by us, no one else is going to if we don't.

eholk: I would like generators. Maybe more people would benefit from this than from portability.

yosh: I think generators could be a lot of trouble. Pin is a problem. Another combinatorial explosion (PinnedIterator/AsyncIterator/AsyncPinnedIterator)?

tmandry: Agreed that async closures are more fundamental, we'll pursue those as part of async iterators. I think async drop is harder than generators.

yosh: I think pinning is an effect. Should look into safe pin projections, move semantics. Have to look into this.

tmandry: I think there's an RFC for pin projection.

yosh: I think pin projection requires unsafe Unpin and drop which takes Pin<&mut Self>.

tmandry: unsure

eholk: async is closer to MVP, might end up with two half-baked features than one well rounded feature. Error messages, composability. Gaps in send bounds, async in traits. Want to make sure we don't have big gaps.

tmandry: async fns are generators so it's the same underlying problems a lot of the time. Agree we should be mindful of gaps in whatever we ship.

eholk: generators might fill in some async gaps though, which would be a point in favor of generators

yosh: Want to make sure we don't distract ourselves from async by shipping generators.

eholk: Maybe wg-generators would be good.

tmandry: Is portability better to do first?

yosh: Seems like we want maybe-async before we tackle portability.

tmandry: Not sure we can ship it next year?

yosh: Have a pretty solid ground for implementation. Blog post was an oops, but I think the problem is real and we need a better syntax. I think if we put our minds to it, I think we could ship [part of it] within a year.

---

## Topic

name: prompt

---

## Topic

name: prompt

---

## Topic

name: prompt

---