2021-Oct: Lang team update

• Owner: tmandry
• Liaison/author: nikomatsakis, currently (looking for a replacement)

Although the async fundamentals initiative hasn't technically formed yet, I'm going to write an update anyhow as "acting liaison". To start, I would like to find another liaison! I think that I am a bit close to the work here and the group would benefit from a liaison who is a bit more distant.

Our overall charter: Make it possible to write async fn in traits, as well as enabling key language features that bring async more into parity with sync:

• Async functions in traits
  • in both static and dyn contexts
• Async drop
• Async closures

This is a key enabler for most of the async vision doc. For example, the various interop traits (e.g., async iteration, async read, async write, etc) all build on async functions in traits.

We have identified an MVP, which aims to support async fn in traits in static contexts by desugaring to an (anonymous) associated GAT plus (on the impl side) a TAIT. We are preparing an RFC describing this MVP and talking to various folks about doing the implementation work.

We are assembling a group of stakeholders that we will talk to in order to get feedback on the MVP and on future design decisions (in addition to the lang team and so forth).

In addition to the MVP, we are drafting an evaluation doc that identifies further challenges along with possible solutions. Once we feel good about the coverage for a particular challenge, we will create targeted RFCs for that specific item.

One specific direction of interest is creating core enablers that can be used to experiment with the most ergonomic syntax or capabilities. As an example, for dyn async traits, there is a need to return some form of "boxed dyn future", but there are many runtiem techniques one might use for this (the most obvious being to return a Box, of course). Supporting those options requires being able to manipulate vtables and the like. It may be an optional to make those kind of "core capabilities" available as simple primitives. This would allow us to experiment with a procedural macro that generates an easy to use wrapper built on these primitives; once we have a clear idea what exactly that should be, we can bring it into the language. (It remains to be seen if this is a better path than trying to build the say thing first and work out the primitives later.)

Niko has also been writing blog posts to walk through the dyn logic in more detail (starting at part 1 and continuing in part 2).