---
title: wg-async meeting 2023-08-24
tags: minutes, wg-async
date: 2023-08-24
url: https://hackmd.io/x8gCTOykQfqoSyGGbZXPlg
---

This is the doc for open discussion within wg-async about various design questions and other topics.

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

# [Analysis of Rust issue #42940](/83sY9XQjSiK79QdnqK0F3Q)

This is the prepared document for today.

# Questions

## Coercion from dyn

tmandry: Is the dyn coercion doing some kind of "magic" to pave over the issue, or does the behavior fall out of rules we would expect?

TC: Type erasure. The problem is that the *type* can't be named outside of the function (due to the lifetime that's valid only within the function). The value can escape but the name of the *type*/*lifetime* cannot. So type erasure "fixes" it.

## Using associated types

tmandry: What does the doc mean "this works"? There is still a "Dummy" placeholder in the code.

..oh, you're saying if you make a Dummy struct and put it there the code compiles. Got it. That seems similar to the idea of using a placeholder type like `_` to signify that the type doesn't matter.

TC: Right.

## Desired outcome

tmandry: What's the desired outcome?

TC: This issue was nominated for wg-async, do we want to fix it?

TC: TAIT is the obvious solution here. Can also have the compiler notice that the hidden type doesn't capture the type parameter.

tmandry: Agreed that TAIT is the way to go. The other way sounds like auto trait leakage, I'm more hesitant about that.

TC: The capture is not part of the opaque type itself.

eholk: Still externally visible in terms of whether code outside the function itself compiles or not.

TC: This is not correct; the capture only affects what lifetimes the hidden type (the concrete return type of the function in this case) is allowed to name. Nothing not named in the opaque type can affect code outside of the function.

eholk: There's something the compiler is considering that isn't written down anywhere. Maybe the capture rules are too generous.

tmandry: In the lang team meeting we decided to make it more consistent, i.e. by having it capture everything. A syntax would be nice but haven't seen a good one yet.

TC: Also, what we decided about making the capture rules more consistent is a separable issue from maybe later adding a syntax to more precisely control the capturing of lifetime and type parameters.

eholk: I like having simpler rules. Explicit syntax might be good. `for<'a>`, `impl<'a>`

---

TC: The problem is that our return type satisfies the `outlives` predicate but we can't return it. That's just weird.

tmandry: Yeah maybe we can come up with some way around it, the compiler is trying to satisfy syntactic rules about lifetime names for which there is no syntax (see `Dummy` in example Example 2.1).

TC: It's also possible to use existential lifetimes here.

Yosh: `'static`?

TC: I don't think it works in this case.