---
tags: weekly-meeting
---

# Types Team: GATs Retro, 2023-04-10

## Agenda

* Did the stabilization go well, anything about that process we can improve going forward?
* What's the status for the issues we accepted during stabilization, and following that, do we have a roadmap for how and when we will fix them?

## Stabilization proceess

### pro: GATs are a majorly useful feature

We don't have a list of users, but anecdotally they are cropping up in a lot of places.

### con: We don't have data on how often GATs are used and how

Following up on the above, I still feel like we're lacking in data for making an "evidence-based" argument for the use of GATs. Are they leaking into public interfaces? Used as an enabler? Both?

### con: Delivering GATs to .. idk .. 4 years?

It took a long time and some disjointed effort by a variety of people to get GATs out the door. This isn't so much a *con* but it does feel like we could've moved more deliberately. It feels like with Rust we're often moving a lot of things at once and I wish we were more focused.

lcnr: i think having a types team (and an official roadmap + roadmap discussions helps here :thinking:). always something to keep in mind but i think we're somewhat okay here now :thinking:

### pro: afaik we didn't encounter any major unintended behavior or bugs after landing the stabilization PR

Given the complexity of GATs as a feature it is really nice to see that we didn't end up with any unfortunate behavior after stabilization.

### con: last minute concerns about whether we want the feature at all generated a disproportionate amount of stress/bad-feeling for the change they produced

There was last minute controversy about whether to have GATs at all that was unexpected. This created a lot of stress amongst the folks driving the work forward and a sense of "deflation" -- hard to stay motivated, which led to long stretches between replies, which is not a great cycle. In the end, we stabilized exactly what we expected to when we started out, so it did not lead to significant change in the outcome. It did however lead to more analysis of use cases. Some of the people who had concerns left the process feeling heard, but others did not.

It'd be good to follow up with nrc specifically because they didn't seem satisfied with the way we responded, but I felt I was trying pretty hard to engage in good faith and respond to their concerns. There was definitely a gap there, and it'd be good to think about how to better receive and incorporate this kind of feedback early on to avoid the stressful fallout. --nikomatsakis

+1 - Jack
I don't really know if there was a better way to approach this from our end. We very clearly made our intent known for more than a year prior to stabilization PR. Maybe more blog posts showcasing the feature and its limitations? idk. That being said, the stabilization PR discussion did generate nice examples and such

lcnr: maybe even publishing some internals blog post "asking for post stabilization gat feedback"?

### con: Summarizing "use cases" is hard

In following up on the feedback on whether GATs are useful, it was hard to come up with a good explanation for the "use cases" around them, in part because they are so varied and broad. We did some deep dives, e.g. the Many Modes pattern, Lazy Iterator, etc, but it didn't feel like a "muscle" that we've exercised very often in describing Rust features, somewhat surprisingly. We didn't have clear templates or paths to follow. For the async function in trait initiative, we've been trying something related, which is gathering up [case studies](https://rust-lang.github.io/async-fundamentals-initiative/evaluation/case-studies.html).

Jack: Regarding use cases, I wish we had more of the "user stories" like the async wg.

### pro: The decisions we made re. where Self:'a clauses dont seem to block anyone

nikomatsakis: +1 -- I'm feeling good about the way we handled that situation. Nice job avoiding 1-way doors and charting a path forward. I'm still unsure what the final result will be, which means we made the right call not to commit.

### con: It's still hard to judge how big of an impact bugs/limitations like implied 'static are.

There are obviously open issues, but its unclear how much they block people from using GATs as a whole.

## Observations / recommendations

**Personas**: It would be helpful to have more of a characterization of what the "Rust user personas" -- what they care about, what they're trying to do.

eholk: I think a lot of the disagreements i see in how to design Rust features comes from people arguing on behalf of different personas.

**RFC amendments:** To help address the above, we could amend RFCs to include explicit sections about who the feature is aimed at, who is it NOT aimed at, what we expect people to like/hate about it.

**Consider fresh RFCs:** it may be useful to write a fresh RFC when a feature was RFC'd several years back, particularly if we've learned things in the meantime. This is more of a lang issue than types in many cases.

## Open issues

### missing implied bounds resulting in `'static` bounds

### required `Self: 'a` bounds cannot be avoided

### dyn safety for traits with gats

### syntax

trait Trait {
    type Assoc<'a>;
}

fn foo<T: Trait<for<'a> Assoc<'a> = &'a u32>>() {}
// or
fn foo<T: Trait<Assoc<'_> = &u32>>() {}

// also

fn foo<T: Trait<Assoc<'_>: Bound>>() {}

### borrowck issues: require polonius