---
title: 2023-12-04 Planning meeting
tags: weekly-meeting, T-types
date: 2023-12-04
discussion: https://rust-lang.zulipchat.com/#narrow/stream/326132-t-types.2Fmeetings/topic/2023-12-04.20planning.20meeting
url: https://hackmd.io/Edf1Pg0SRUaSw9JIdwF1Tg
---

# T-types planning meeting agenda

## Updates

### [Tracking issue for shared type library](https://github.com/rust-lang/types-team/issues/16)

> Michael has made many PRs towards this effort!:
rust-lang/rust#116828
rust-lang/rust#116912
rust-lang/rust#116946
rust-lang/rust#116951
rust-lang/rust#116993
rust-lang/rust#117008
rust-lang/rust#117578
rust-lang/rust#117580
rust-lang/rust#117582
rust-lang/rust#117851

### [Tracking issue for AFIT and RPITIT](https://github.com/rust-lang/types-team/issues/66)

AFIT and RPITIT are stabilized with Rust 1.75.

Work on subsequent useful features (e.g. RTN) has kind of stalled due to dependence on the new trait solver.

### [Tracking issue for TAITs](https://github.com/rust-lang/types-team/issues/67)

The plan is to first stabilize Mini-TAIT.

### [Minimal version of TAITs (Mini-TAIT)](https://github.com/rust-lang/types-team/issues/107)

In the October 2023 T-types meetup, we had a great and very collaborative session on TAIT that resulted in a proposal for a minimal TAIT stabilization named Mini-TAIT. We [presented](https://hackmd.io/CDj92gZdTzilDWORdKhLQA) this to T-lang on 2023-11-08. However, there were only 3 T-lang members present, and the meeting failed to gain consensus as discussion revisited the [#107645 FCP](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789814) about how we notate what items are allowed to define the hidden type of some opaque.

To disentangle things, as the key aspects of the Mini-TAIT proposal are orthogonal to this notation, we've made T-lang nominations for each aspect of Mini-TAIT:

- [Once modulo regions restriction - #116935](https://github.com/rust-lang/rust/pull/116935#issuecomment-1807243974)
- [May define implies must define restriction - #117861](https://github.com/rust-lang/rust/issues/117861#issue-1989842470)
- [May define may guide inference - #117865](https://github.com/rust-lang/rust/issues/117865#issue-1990005181)
- [Whether nested inner items may define - #117860](https://github.com/rust-lang/rust/issues/117860#issue-1989813479)

There is a dual T-lang/T-types FCP also related to TAIT (but also to RPIT) ongoing here:

- [Exhaustiveness: reveal opaque types properly - #116821](https://github.com/rust-lang/rust/pull/116821)

And we're proposing a new Mini-TAIT restriction here:

- [Must define before use restriction - #117866](https://github.com/rust-lang/rust/issues/117866#issue-1990323059)

The hypothesis is that this restriction could make it more plausible to later lift the "may define implies must define" restriction.

### [UnlimiTAIT](https://github.com/rust-lang/types-team/issues/115)

Blocked on first stabilizing Mini-TAIT.

### [RPIT capture all lifetimes](https://github.com/rust-lang/types-team/issues/110)

The RFC was accepted:

https://github.com/rust-lang/rfcs/pull/3498

The tracking issue is:

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

There's a PR for the implementation here:

https://github.com/rust-lang/rust/pull/116952

Stabilizing this in Rust 2024 is contingent on TAIT or some other solution for expressing precise captures stabilizing.

### [Tracking issue for GATs](https://github.com/rust-lang/types-team/issues/68)

No update

### [Tracking issue for a-mir-formality](https://github.com/rust-lang/types-team/issues/69)

No update

### [Tracking issue for subtyping refactor](https://github.com/rust-lang/types-team/issues/70)

>update: there's no work going on here. discussed the long term goal in the types team meetup, but are currently not working on it.

### [Tracking issue for implied bounds refactor](https://github.com/rust-lang/types-team/issues/71)

>update: mostly blocked on new-solver, though @aliemjay is doing some work using the existing setup

### [Tracking issue for trait object upcasting](https://github.com/rust-lang/types-team/issues/72)

Trait object upcasting is stable on nightly and is scheduled to go out with Rust 1.76.

The T-lang FCP happened here:

https://github.com/rust-lang/rust/issues/65991#issuecomment-1670127881

This is the stabilization PR:

https://github.com/rust-lang/rust/pull/118133

### [Tracking issue for negative impls](https://github.com/rust-lang/types-team/issues/73)

Not much has updated on negative impls themselves.

Core now uses the new trait solver for negative coherence. It's a very cool algorithm.

We have experimental support for negative trait bounds for testing purposes.

Note that t-lang formed consensus on a plan to stabilize a subset:

https://github.com/rust-lang/rust/issues/68318#issuecomment-1832355185

There is a draft RFC here:

https://hackmd.io/ZmpF0ITPRWKx6jYxgCWS7g

There is also discussion of wanting "questionable trait impls":

https://github.com/rust-lang/rust/issues/68318#issuecomment-1832389222

### [Tracking issue for rust trait solver refactor](https://github.com/rust-lang/types-team/issues/76)

This is tracked separately in:

- https://github.com/rust-lang/types-team/issues/105
- https://github.com/rust-lang/types-team/issues/112

### [Model coherence in formality](https://github.com/rust-lang/types-team/issues/103)

No update

### [Normalize in orphan check](https://github.com/rust-lang/types-team/issues/104)

Update: WIP PR by @fmease in https://github.com/rust-lang/rust/pull/117164

### [New solver in coherence](https://github.com/rust-lang/types-team/issues/105)

Update: see https://lcnr.de/update/2023-12-01, main blocker is non-fatal overflow handling in the new solver.

### ["Semantic outlives" for opaque aliases](https://github.com/rust-lang/types-team/issues/106)

No update

### [Prototype of Polonius](https://github.com/rust-lang/types-team/issues/108)

>Status on roadmap/WG/location-insensitive prototype:
> - up-to-date roadmap [published](https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-update.html)
> - location-insensitive analysis landed in rustc, with empirical evaluation that this is equivalent to NLLs until a-mir-formality formalism is available:
> * differential testing via tests, fuzzing, and crater: asserting no differences in scopes compared to NLLs'
> * fuzzing: has uncovered 2 issues, now fixed
> * [crater runs](https://github.com/rust-lang/rust/pull/117593):
> - first run uncovered a difference on 10 crates, same root cause
> - [fix PR landed](https://github.com/rust-lang/rust/pull/118175), clean results on second run
> - various cleanups of borrowck, NLLs, and legacy polonius have landed
> - onboarding Amanda, starting with higher-ranked task from the roadmap
> - no new progress on borrowck/polonius in a-mir-formality just yet on our side, but there are plans in ralf's team
> - moving on to location-sensitivity

>Current status on location-sensitive prototype:
>- the most up-to-date details about future prototyping are in this [hackmd](https://hackmd.io/F9ZiqVWtSpuNIO_bmCQphg?both), and evolved out of the two [previous](https://smallcultfollowing.com/babysteps/blog/2023/09/22/polonius-part-1/) [descriptions](https://smallcultfollowing.com/babysteps/blog/2023/09/29/polonius-part-2/)
>- we've started looking into realizing this design in-tree, but it's still early days

### [Enforce where-clauses on type aliases via alias type](https://github.com/rust-lang/types-team/issues/111)

This was the subject of the 2023-11-29 T-lang design meeting:

https://hackmd.io/LCUSAX5LSfqc4m7N4CWNPw

The T-lang consensus was:

> *Consensus*: We're OK with going forward in the 2024 edition with type aliases being weak and working analogously with structs. We accept the fact that people may have to add redundant where clauses, even though we may relax that later. This path is forward compatible with later relaxing these rules within an edition. We won't block stabilizing this in Rust 2024 on other improvments to implied bounds being made. At the same time, we're open to future or concurrent work along two axes: 1) better unifying type aliases with other alias types (e.g. associated types), and 2) improving implied bounds generally for all alias types.

### [Use the new trait solver in all the places](https://github.com/rust-lang/types-team/issues/112)

Update: currently focussing on stabilizing `-Ztrait-solver=next-coherence` first.

### [Support negative impls in coherence](https://github.com/rust-lang/types-team/issues/113)

Blocked on new solver with non-empty environments ~> post `-Ztrait-solver=next-coherence`.

### [Location-sensitive polonius](https://github.com/rust-lang/types-team/issues/114)

No update

### [Coinduction](https://github.com/rust-lang/types-team/issues/116)

No update

### [Instantiate implied bounds explicitly](https://github.com/rust-lang/types-team/issues/117)

No update

### [Perfect derive](https://github.com/rust-lang/types-team/issues/118)

No update

### [Specialization](https://github.com/rust-lang/types-team/issues/119)

No update

### [Avoid inference guessing in trait solver (e.g., favoring where-clauses over impls)](https://github.com/rust-lang/types-team/issues/120)

>update: not actively worked on, requires the solver to be more settled, currently not a main focus.

### [Avoid bounding impl trait return type by all input type parameters using existential lifetimes](https://github.com/rust-lang/types-team/issues/121)

No update

### [Implied bounds on higher-ranked binders](https://github.com/rust-lang/types-team/issues/122)

No update

### [Full triage of all soundness issues](https://github.com/rust-lang/types-team/issues/123)

No update

## Nominated issues

### [Tracking Issue for raw slice len() method (slice_ptr_len, const_slice_ptr_len)](https://github.com/rust-lang/rust/issues/71146)

>I think this has been sitting around long enough, clearly a fix for https://github.com/rust-lang/rust/issues/73987 will not magically materialize. And even with https://github.com/rust-lang/rust/issues/73987 unresolved, as long as we don't let users write arbitrary-self methods on raw pointers, we can still change the autoref behavior later to use raw pointers when that is enough. So while these methods might have a footgun, they are still better than the status quo.

>So I propose we move towards stabilizing this, and https://github.com/rust-lang/rust/issues/71146.

>@rust-lang/types are you aware of anything that would block stabilizing a function that uses a raw slice pointer self type? (AFAIK these would be the first stable functions that do that.)

### [Tracking Issue for raw slice getters (slice_ptr_get)](https://github.com/rust-lang/rust/issues/74265)

>I think this has been sitting around long enough, clearly a fix for https://github.com/rust-lang/rust/issues/73987 will not magically materialize. And even with https://github.com/rust-lang/rust/issues/73987 unresolved, as long as we don't let users write arbitrary-self methods on raw pointers, we can still change the autoref behavior later to use raw pointers when that is enough. So while these methods might have a footgun, they are still better than the status quo.

>So I propose we move towards stabilizing the raw pointer part of this. (I am less sure about the `NonNull` part.)

>@rust-lang/types are you aware of anything that would block stabilizing a function that uses a raw slice pointer self type? (AFAIK these would be the first stable functions that do that.)

## Types FCPs

### [fix fn/const items implied bounds and wf check](https://github.com/rust-lang/rust/pull/104098)

### [relax leak-check](https://github.com/rust-lang/rust/pull/112999)

### [Exhaustiveness: reveal opaque types properly](https://github.com/rust-lang/rust/pull/116821)

### [Prevent opaque types being instantiated twice with different regions within the same function](https://github.com/rust-lang/rust/pull/116935)

### [Support async recursive calls (as long as they have indirection)](https://github.com/rust-lang/rust/pull/117703)

### [Make `IMPLIED_BOUNDS_ENTAILMENT` into a hard error from a lint](https://github.com/rust-lang/rust/pull/117984)

## Major change proposals

### [Add experimental support for implication predicates](https://github.com/rust-lang/types-team/issues/80)

Closed as accepted

### [Type system refactorings for further `rustc_type_ir`-ification](https://github.com/rust-lang/types-team/issues/124)

Closed as accepated.

## Deep dive planning

### [Variance and Rust](https://github.com/rust-lang/types-team/issues/45)

### [discuss the `trait_alias` feature](https://github.com/rust-lang/types-team/issues/49)

### [Closure return type outlives guarantees](https://github.com/rust-lang/types-team/issues/57)

### [ Account for late-bound lifetimes in generics #103448 ](https://github.com/rust-lang/types-team/issues/62)

### [Negative trait impls check-in](https://github.com/rust-lang/types-team/issues/82)

### [Coinductive trait semantics and normalization](https://github.com/rust-lang/types-team/issues/83)

### [Specialization](https://github.com/rust-lang/types-team/issues/89)

### [Deep dive for leak check/higher ranked fn ptr subtyping](https://github.com/rust-lang/types-team/issues/96)

### [discuss "incorrect implied bounds in wfcheck"](https://github.com/rust-lang/types-team/issues/99)

### [dyn safety and coherence](https://github.com/rust-lang/types-team/issues/100)

### [`'erased` during analysis](https://github.com/rust-lang/types-team/issues/101)

### [unsound issues fun time](https://github.com/rust-lang/types-team/issues/125)