---
title: "Design meeting 2024-07-25: Open discussion"
tags: ["WG-async", "design-meeting", "minutes"]
date: 2024-07-25
discussion: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Meeting.202024-07-25
url: https://hackmd.io/bxSCZ2FnQcGeEvF89PwIjg
---

# Discussion

## Attendance

- People: compiler-errs, Daria, TC, Eric, Yosh, tmandry, Vincenzo

## Meeting roles

- Driver: TC
- Minutes: Yosh

## Freeze

(general discussion): Is `Freeze` an auto-trait?

Daria: currently `impl<T> Freeze for PhantomData<T>`:

https://doc.rust-lang.org/std/marker/trait.Freeze.html#impl-Freeze-for-PhantomData%3CT%3E

Daria: Also we have Unpin, UnwindSafe, RefUnwindSafe as auto traits btw, perhaps some conditions could be infered from these.

## Async closures

Eric: I feel like we should make more progress on async closures, and it's not worth holding up on syntax.

Eric: Syntax is something we can also change across editions, so even if we get it wrong it's something that we can fix later on. It's not ideal, but it can be done.

Errs: I have proposed a design, I like that design. I don't want to also push the convincing part of things (paraphrasing).

Errs: I don't want to hold up this design indefinitely either. We all seem to be in agreement here. There is a version where we can land `AsyncFn` - though that would be a worse design.

Eric: Agreed (that `async Fn` would be better).

## What comes next?

Errs: unsafe binders seem like a good next one. Would like to enable people to use async closures with manually authored futures.

Eric: I was just running into this when I was working on my async generators RFC. `map` and `merge` are the combinators I'm having some issues with.

## Pinning

Eric: TC and I were talking about pinning. Boats published some posts. This is also related to move trait. Pin as a language feature seems promising.

Errs: we should be able to decouple some of the semantics and language sugar for some of the conveniences being discussed. Would love if we for example didn't have to call `.get_mut` on every single reborrow. That might be involved, but can probably do it.

Errs: My understanding that some of the appeal of improvements to pin is that we can improve the underlying struct. Reborrowing improvements seem like they can be part of the `Pin` type.

(tmandry joins the meeting with a crash zoom..)

(discussion about a `Reborrow` trait)

TC: There's ongoing work on smart pointers, e.g. `#[derive(SmartPointer)]`. It seems that at least some of these would want reborrowing also, which may suggest the desirability of a trait here, eventually.

Errs: Not all types have a consistent notion of what reborrowing is - so we'd somehow need to capture that.

Daria: Opposed to any sugar that makes types behave magically. Which capabilities would we give to pinned references?

Errs: We'd want to make pin easier to use. The second is to add sugar. We can bikeshed whether `&mut pinned` is useful or not, but we can discuss that separately from ergonomic improvements to `Pin` itself.

(errs provides a motivating example about `.get_mut` and reborrows)

Eric: I don't love the idea of taking structs in the lib and blessing them / making them special. I feel better about doing that for traits than I do for structs - not sure why though.

Eric: If we did get a pin reference type, I would like them to be transparently convertible to the existing `Pin` references.

Errs: What you're asking for is a coercion. When two things are [similar but not the same you run into issues] (note: is this the right summary?).

Daria: why don't we have (intersection of) two types in Rust? (thinking about making my own language here lol)

Errs: It would be bad for subtyping among other things.

Errs: I think we can decouple things to enable people to have better things sooner. That's been a motivating force in my Rust work. (talks about coerce unsized).

Yosh: I think there's value in improving ergonomics in the short term, but in the long term we may want to evaluate the designs more closely. Pin is a much more constrained scope than generalized self-referential types. Believe there is value to have the broader feature.

Errs: it's why I think we should separate the short-term from long-term (paraphrasing)

Eric: agree, making pin more ergonomic does not solve all the problems. Pin ergonomics would help with some manual future impls. Can add features to solve other problems in the future, and better ergonomics around pinning can make it easier to get to those features.

- Eric's post: [Two ways not to Move](https://theincredibleholk.org/blog/2024/07/15/two-ways-not-to-move/)

Eric: learned about the difference between the two framings of `Move` just two weeks ago.

Eric: The old definition has a single trait which has two phases: movemovable and immovable. Types implementing `Move` can be freely moved until a certain point, after which they can't.

Eric: (describing issues with that model)

Eric: (describes the other model and its tradeoffs)

TC: Some of the decisions here read on decisions we need to make today, e.g, "do we need to bet on `IntoFuture`?". Doing `Move` with the semantics eholk proposes would require leaning on `IntoFuture`.

Eric: It's good to get more clarity on what problems are being solved by `!Move` which aren't solved by pin ergonomics.

Daria: I've worked with unforgettable types which have a `?Forget` bound - that feels like a similar problem.

Eric: That's a good point, did you figure out a solution for that?

Daria: yeah - there should be a default bound. Basically any old code must never operate on unforgettable types.

Yosh: part of why I started writing about immovable types is because of the common thread with unforgettable types - I think there is a common thread here in the way solutions need to be shared.

Daria: I don't think traits like Move or Forget are very strange at all. It's mainly that we didn't add them at 1.0. I don't think they're magical (different from other auto traits).

(The meeting ended here.)