---
title: "T-types stabilization process"
date: 2023-10-09
tags: T-types, 2023-meetup-BRU, minutes
url: https://hackmd.io/aHnGavgaTnmQiNAiE9tC3g
---

# Stabilization process

## Expected outcomes

* Rough outline for stabilization process

## Background

- types team is responsible when stabilizing type system related stuff
- the type system is a very complex and interconnected system, easy to get wrong
- conflicting priorities when stabilizing new features
- make progress to keep increasing adoption, enable users
- avoid longterm issues due to backwards compatability/technical debt
- maintain soundness, by not directly introducing new soundness holes and by avoiding footguns in the implementation
- it's an enjoyable - or at least tolerable - process for the people involved
- avoiding a significant burden on T-types and other contributors, we only have a fairly limited capacity

### the current feature pipeline

- informal discussions on zulip/internals/reddit/blogposts
- often with limited to no types team involvement
- there is a lot of activity here
- often: lang MCP? working group? RFC
- not going in-depth wrt to type system interactions
- often with limited types team involvement (apart from niko as he's also lang)
- many existing proposals from before the creation of the types team
- implementation + practical design work
- implemented by different contributors, sometimes fairly new ones
- implementation often stalls while being incomplete/broken
- implementation decisions often get lost, remain undocumented
- quite reactively handling issues whenever people open issues
- resulting in local fixes of more general issues/problems with the design
- stabilization
- stabilization report
- requires lang (probably) and types approval
- mention all the implementation decisions/changes from the RFC
- reference
- complete documentation of user-facing language changes
- rustc-dev-guide
- implementation documentation of the design, all affected areas
- a-mir-formality?
- tests

### case studies

Dyn upcasting coercion [#65991](https://github.com/rust-lang/rust/issues/65991)
- original stabilization proposal did not explore type system changes
- https://github.com/rust-lang/rust/issues/65991#issuecomment-1713996081 stabilization is now blocked on types team involvement. @nikomatsakis did someone reach out to be mentored here?
- errs: blocked on adding support to a-mir-formality, but who is equipped to do that? It's not clear how to do it because it's still in "what needs to be done" territory. Nobody else can approve PRs. I want it to land. I think the FCP needs more technical discussion. I think it could be landed if somebody wrote it up in enough detail.
- lcnr: we clearly had issues there. but now that we have the requirement for a-mir-formality, nobody has volunteered, so now it's just kind of stuck. But needs *something*.
- (the issues: https://github.com/rust-lang/rust/pull/114036)
- nikomatsakis: I like having stabilization FCPs take place on a dedicated issue. The PR is ok too. I feel like it'd be nice to separate out the lang vs types team discussions, I think the lang team tradeoffs WERE well documented (but maybe not included in the stabilization *report* per se).
- lcnr: see next case study. Links to all the areas for that feature. That at least would be useful, e.g. for upcasting. Expert can then review that.
- nikomatsakis: I like linking to dev-guide or initiative repo, since the PR text is kind of a "memory hole", probably it should be most links, and it should be on the initiative repo.

AFIT and RPITIT [#115822](https://github.com/rust-lang/rust/pull/115822)
- relies on RPIT which is messy, but does not do so in weird new ways, so it's fine not to mention it?
- apart from this nearly all t-types interactions are documented?
- RPITIT has fun interactions with implied bounds which were nearly missed
- https://github.com/rust-lang/rust/pull/116072 fix opened after the start of the FCP, iirc not mentioned in the stabilization report or the dev-guide

TAIT [#63063](https://github.com/rust-lang/rust/issues/63063)
- stabilization had `|T-lang| - 2` approvals and entered [FCP](https://github.com/rust-lang/rust/issues/63063#issuecomment-1361432978) which was then [blocked on updating the `reference`](https://github.com/rust-lang/rust/issues/63063#issuecomment-1364525286)
- the [stabilization report](https://hackmd.io/tB3V8MP5S66zHIWTUdRvQw) describes the user-facing impact of the feature, does not explore impl decisions
- the impl was not ready at the time the stabilization was proposed (there were also some lang design changes after the FCP)
## Key questions for discussion

The key question is *whether* and *how* to improve the stabilization process for types team decisions. Maybe during lunch?

### Did a significant Types Team issue ever slip through

We still haven't reached *a very good design/impl* for RPIT? There are currently [2 unsound issues](https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AI-unsound+label%3AA-impl-trait). There are multiple backcompat hacks for it as well. I still feel like it was alright-ish to stabilize it? TAIT stabilization nearly slipped through.

### Priorities for stabilization

May be good to have some chats about our priorities, not necessarily rn. From @BoxyUwU "would be nice maybe to have a policy of not stabilizing features that have soundness bugs that are not just "the same" as pre-existing ones".

### Ideas on how to improve the process

- add checklists/template for stabilization reports
- make sure reference and stuff is updated, implementation decisions are explored
- T-types specific checklist of "do we handle these subtle areas if applicable"
- require either a rustc-dev-guide entry mentioning all affected places in the code, or directly links to the source for smaller changes
- FCP proposal: differentiate between "idk, should be fine, going to trust others" and "yes, I am confident the feature should be stabilized"
- would probably have helped with https://github.com/rust-lang/rust/pull/116040

### Related issues

Require a T-types FCP when using unstable features in std. We're currently stuck with specialization because std uses it in a user-facing way: "does `vec.into_iter().collect::<Vec<_>>()` allocate". This is blocking changes to specialization, which is an issue given that it is hard to soundly support with the new solver. There have also been attempts adding `feature(generic_const_exprs)` to std. Potentially add an "allowed features in std" file checked by tidy and pinging T-types if it is changed?

## Notes, minutes from the meeting itself

## Questions

### dyn Trait upcasting

https://github.com/rust-lang/rust/issues/65991

CE: I feel this is blocked without a clear path forward.

lcnr: The original FCP didn't have enough details at all.

CE: It feels too defensive.

Jack: We want things proven out in a-mir-formality, but that should be early in the process.

NM: I'm fine unblocking it. The FCP there didn't go into detail on the implementation. But it did go into detail on the T-lang issues, the user-facing issues. So it's an issue of things going well and things that could be better.

### Have there been any recent features proposed/accepted that overlap with T-types?

The case studies are all "old". I guess RPITIT?

lcnr: Linking to the relevant source code could be useful to the experts.

NM: Linking to the dev guide makes me happy, as it's persistent. I'd like stabilization reports to link to other persistent documents in general.

Jack: The stabilization report shouldn't have any new questions. One thing that is difficult is when new questions come up in the thread where the stabilization report is posted.

NM: I liked how this worked out. We kept older drafts:

https://rust-lang.github.io/dyn-upcasting-coercion-initiative/design-discussions/upcast-safety-2.html

TC: To Niko's point about persistent documents, as well as to the point of adding more detail to stabilizations, one option is to use RFCs and the RFC process for stabilization.

(Discussion about pros/cons of that.)

NM: I really like having repositories for things.

NM: I would like a stabilization report that has sections per team.

NM: Part of this is a cultural issue; i.e. reminding people to do things and fill things in. Maybe the template should be a kind of checklist that's started after the RFC is accepted that leads toward stabilization.

### Niko thoughts

Strong agree with template on stabilization reports, these are confusing right now. I think making progress on a-mir-formality / spec would help here too.

Would like to modify rfcbot to enable t-types members to block any t-lang stabilization. (I'd probably be ok allowing *ANY* rust team member to block *ANY* stabilization, but allow the team to override that block; lang has a policy that we can also override the objection).

Brute force change would be to add t-types as FCP to all stabilization. I'm reluctant to do that because slow. But maybe it's a good idea.

(TC: Another brute-force approach; an +I-lang-nominated with a list of concerns from a T-types member (or the team as a whole) would almost certainly have the same effect.)

One thing I really like:

When stabilizing, make it very concrete what the questions for each team are. I've tried to do this but I think we could do better.

### some notes

- Jack: What do we do with questions that come up after stabilization FCP starts?

nikomatsakis: similar things arose with this specific question, I made the link...

- https://rust-lang.github.io/dyn-upcasting-coercion-initiative/design-discussions/upcast-safety-3.html
- https://rust-lang.github.io/dyn-upcasting-coercion-initiative/design-discussions/upcast-safety-2.html
- https://rust-lang.github.io/dyn-upcasting-coercion-initiative/design-discussions/upcast-safety.html

Stabilization template:

* Summarize the motivation and user impact
* This is typically covered by the RFC, so you can copy that in, but there may have been new changes in the meantime.
* Scope relative to RFC
* Were (major) new bits of functionality added that were not covered by the RFC?
* Are there things that were described in the RFC which are not covered by this stabilization?
* List each of the unresolved issues that appeared in the RFC and describe how it was resolved
* Open and closed doors
* What decisions are we making now
* Are there unfinished bits of design that we are "partially determining" by the stabilization choices here?
* What decisions do we expect to make in the future
* Did we put limitations in place to ensure that we can make those decisions without breaking people?
* Language changes (T-lang)
* T-lang fcp is (possibly) needed if...
* There are new bits of syntax
* There are stdlib additions that required modification to the compiler
* There are new lints
* If in doubt, nominate the stabilization report for T-lang.
* Specific questions to answer (do not remove the questions, even if answer is no):
* Has the reference been updated? (link to PR(s))
* Does this interact with temporary lifetimes?
* Library changes (T-libs)
* T-libs fcp is (possibly) needed if...
* There are new stdlib APIs
* There are new lints
* Specific questions to answer (do not remove the questions, even if answer is no):
* ???
* Type system changes (T-types)
* Describe any modifications to the trait solver?
* Specific questions to answer (do not remove the questions, even if answer is no):
* Is inference affected, e.g. in HIR typeck?
* Is MIR typeck/borrowck affected?
* How does this interact with implied bounds?
* Modifications to the trait solver with links
* new solver
* `evaluate`/`confirm`/`fulfill`/`project`/`Instance::resolve`
* How does it handle ambiguity and aliases
* Syntax changes (T-style)
* T-style fcp is (possibly) needed if...
* Does this add new syntax that might need changes to the style guide?
* Major compiler changes
* Describe how the implementation fit into the compiler.
* Were major new additions needed?
* Were new compiler flags added?

Next steps:

* RFC for stabilization process
* That there is a checklist
* That you should put the contents on the PR and FCP there
* Each team manages the questions in their section; new teams can be added as needed
* Publish in forge and rustc-dev-guide (and link back and forth)
* Update the stabilization PR and link to the template

https://docs.google.com/drawings/d/11KtHLYsqJzi2_Y3mOBz2FbXeG3verSHz-PFBuiwYIQw/edit

FCP process:

* it'd be nice to support abstrain, the lang-team decision process would help
* https://lang-team.rust-lang.org/decision_process.html