Proposal

In the current implementation, gen/async/async gen blocks and closures have type Coroutine(..) and CoroutineClosure(..). Those types implement Iterator, Future or AsyncIterator depending on the initial desugaring.

This creates a lot of complexity:

• trait solvers must check which kind of coroutine each time;
• MIR StateTransform needs to fixup types depending on the coroutine kind.

I propose to change the desugaring for coroutines to:

• gen { .. } becomes CoroutineIterator::from_coroutine(#[coroutine] { .. });
• async { .. } becomes CoroutineFuture::from_coroutine(#[coroutine] { .. });
• async gen { .. } becomes CoroutineAsyncIterator::from_coroutine(#[coroutine] { .. }).

This way, all coroutines implement std::ops::Coroutine and core is responsible for translating this to user-friendly traits. All the complexity is pushed to error-reporting code, which is not soundness-critical.

Coroutine closures are a little more complex, as we need to keep the CoroutineClosure type for borrow-checking.

Mentors or Reviewers

This involves MIR manipulation and trait solving, so @oli-obk and @lcnr need to know.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.