# Open discussion: June 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.

---
- (Vincent): I seem to have lost track of the `#[refine]` macros. Would it be possible to provide a brief introduction to them?
- (Vincent): I came across Niko's post discussing async stabilization. It would be helpful to identify the specific issues we need to address before entering the freeze period. Are there any particular polishing tasks or issues that we should focus on?
- (added by Vincent idea from eholk): Discussing our triage process https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Triage.20Process
- Governance update - Leadership council and t-launching-pad

---

## #[refine]

- (Vincent): I seem to have lost track of the `#[refine]` macros. Would it be possible to provide a brief introduction to them?

Canonical example is a trait like this:

trait IntoIter {
    type Item;
    fn into_iter(self) -> impl Iterator<Item = Self::Item>;
}

impl<T> IntoIter for MyVec<T> {
    type Item = T;
    fn into_iter(self) -> impl Iterator<Item = T> { ... }
}

Let's say you want to add new details; the RFC proposes adding an attribute called `#[refine]` for that..

impl<T> IntoIter for MyVec<T> {
    type Item = T;
    #[refine]
    fn into_iter(self) -> impl DoubleEndedIterator<Item = T> { ... }
}

let's look at an example user of this trait...

fn process_container<C: IntoIter>(input: C) {
    ...
}

they might want RTN...

fn process_container<
    C: IntoIter<into_iter(): DoubleEndedIterator>
>(input: C) {
    ...
}

But auto traits still leak, even without `#[refine]`. :(

---

tmandry also wants to add a lint against (implicit) auto trait leakage on `pub` functions/methods.

eholk: :+1:

tmandry: The only problem is we don't have a way to be explicit with `async fn`. Some ideas:

* `async(Send)`
* `#[refine(Send)]` ..nevermind, that only makes sense in the context of a trait impl
* `#[async(Send)]`

---

## Stabilization/implementation issues

(Vincent): I came across Niko's post discussing async stabilization. It would be helpful to identify the specific issues we need to address before entering the freeze period. Are there any particular polishing tasks or issues that we should focus on?

https://github.com/rust-lang/rust/labels/F-return_position_impl_trait_in_trait
https://github.com/rust-lang/rust/labels/F-async_fn_in_trait

Blockers for stabilization:

* [#112194](https://github.com/rust-lang/rust/issues/112194): Unclear what the right behavior is
* https://github.com/rust-lang/rust/issues/108304 maybe

https://github.com/rust-lang/rust/issues/74497 -- [playground](https://www.rustexplorer.com/b#%2F*%0A%5Bdependencies%5D%0A%0A*%2F%0A%0Ause%20std%3A%3Afuture%3A%3AFuture%3B%0A%0Apub%20async%20fn%20bar()%20%7B%0A%20%20%20%20foo(%7Cx%7C%20baz(x)).await%3B%0A%7D%0A%0Apub%20async%20fn%20baz(x%3A%20%26u8)%20-%3E%20bool%20%7B%0A%20%20%20%20if%20*x%20%3D%3D%201%20%7B%0A%20%20%20%20%20%20%20%20false%0A%20%20%20%20%7D%20else%20%7B%0A%20%20%20%20%20%20%20%20true%0A%20%20%20%20%7D%0A%7D%0A%0Apub%20async%20fn%20foo%3CF%2C%20T%3E(f%3A%20F)%20-%3E%20bool%0Awhere%0A%20%20%20%20F%3A%20Fn(%26u8)%20-%3E%20T%2C%0A%20%20%20%20T%3A%20Future%3COutput%20%3D%20bool%3E%2C%0A%7B%0A%20%20%20%20f(%2632).await%0A%7D%0A%0Afn%20main()%20%7B%7D)

---

## Triage meeting

https://rust-lang.github.io/wg-async/triage.html

eholk: Should we update the triage instructions to reflect reality?

https://forge.rust-lang.org/compiler/prioritization/priority-levels.html

Let's start assigning priorities, focus the purpose of the meeting on prioritization, not debugging.

Do we still want the project board?

https://github.com/orgs/rust-lang/projects/29/views/1

vincent: We can use for categorizing issues. I also find it useful for keeping track myself.

tmandry: Feel free to try adding a custom field for categorizing

---

## Topic

name: prompt

---