---
title: Triage meeting 2022-04-26
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-04-26

## Attendance

* Team members: Felix, Josh, Taylor
* Others: Mark, Jane, Jack

## Meeting roles

* Action item scribe: Mark
* Note-taker: Felix

## Scheduled meetings
- "Structural equality" [lang-team#94](https://github.com/rust-lang/lang-team/issues/94)
- "Never allow unwinding from Drop impls" [lang-team#97](https://github.com/rust-lang/lang-team/issues/97)
- "Dyn upcasting, safety considerations" [lang-team#119](https://github.com/rust-lang/lang-team/issues/119)
- "Const eval overview" [lang-team#131](https://github.com/rust-lang/lang-team/issues/131)
- "Return Position impl Trait in dyn Trait ("RPITIDT")" [lang-team#144](https://github.com/rust-lang/lang-team/issues/144)

## Announcements or custom items

* Jack: planning for stabilization of GATs, (perhaps tied to 1.61 release circa May 19th). Any issues that you all want covered?
* Josh: Which items is this blocking?
* Jack: lending iterators, some aspects of async iterators (streams)
* pnkfelix: nothing re stablization report itself, but maybe plan a doc/blog post overviewing what this enables (for libstd but also for 3rd party crates)?
* Jack: yes, planning as part of shiny future blog post
* Josh: there is pain re portability across tokio and async-std. So, if GATs and TAIT and async fn in traits helps std ship the traits necessary to make portable code, that is great.
* Tomorrow design meeting for 2022-04-27: Backlog Bonanza!

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals
### "Deprecate target_vendor " lang-team#102

**Link:** https://github.com/rust-lang/lang-team/issues/102

### "Support platforms with size_t != uintptr_t" lang-team#125

**Link:** https://github.com/rust-lang/lang-team/issues/125

### "Positional Associated Types" lang-team#126

**Link:** https://github.com/rust-lang/lang-team/issues/126

### "Interoperability With C++ Destruction Order" lang-team#135

**Link:** https://github.com/rust-lang/lang-team/issues/135

### "inner crates, aka multiple crates per file" lang-team#139

**Link:** https://github.com/rust-lang/lang-team/issues/139

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

**Link:** https://github.com/rust-lang/lang-team/issues/143

### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

**Link:** https://github.com/rust-lang/lang-team/issues/147

### "Async fns in traits" lang-team#150

**Link:** https://github.com/rust-lang/lang-team/issues/150

### "dyn* trait" lang-team#158

**Link:** https://github.com/rust-lang/lang-team/issues/158

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

**Link:** https://github.com/rust-lang/lang-team/issues/160

### "Initiative: Ghost types and blocks" lang-team#161

**Link:** https://github.com/rust-lang/lang-team/issues/161

### "Keyword generics" lang-team#162

**Link:** https://github.com/rust-lang/lang-team/issues/162

## PRs on the lang-team repo

None.

## RFCs waiting to be merged
### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216

**Link:** https://github.com/rust-lang/rfcs/pull/3216

### "RFC: Add `target` configuration " rfcs#3239

**Link:** https://github.com/rust-lang/rfcs/pull/3239

* Felix takes action item to merge this.

## Proposed FCPs

**Check your boxes!**
### "Tracking issue for `explicit_generic_args_with_impl_trait`" rust#83701

- **Link:** https://github.com/rust-lang/rust/issues/83701
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/83701#issuecomment-1109958362):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/83701#issuecomment-1109958337):
> It seems reasonable to me to allow omitting the impl Trait parameters in a turbofish; we could always make their specification optional in the future.

>

> T-lang, shall we allow turbofish for standard generic type parameters in a function that also has impl Trait parameters?

>

> @rfcbot merge

* pnkfelix: petrochenkov posted a [concern](https://github.com/rust-lang/rust/issues/83701#issuecomment-1097732510); has it been addressed?
* joshtriplett: by adopting this, we would not be closing the door on allowing turbofishing `impl Trait` parameters in the future. but we would be closing the door of *requiring* them to be specified.
* cramertj: I'm more concerned that we're leaving the door open for turbofishing those in the first place. I support the syntax and stabilization being proposed here, but would go further and say that we're not going to support turbofishing `impl Trait` parameters in the future.
* joshtriplett: I don't want to block movement on this feature based on concerns about what extensions might be added to turbofishing in the future. It seems like it should suffice to acknowledge "by doing this, we may be complicating adding support for that, and we accept that."
* cramertj: Looked at petrochenkov's comment, some concern about converting between `impl Trait` and explicit generic args
* joshtriplett: Could add syntax to make that work, e.g. `<E: ExistingParam, S: SomeTrait = _>`.

### "Stabilize `let else`" rust#93628

- **Link:** https://github.com/rust-lang/rust/pull/93628
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383585):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * need-consistency-rvalue-temporary-rules-between-let-and-let-else (https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523)
> * ~~not-while-rustfmt-breaks-on-it~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1032936704
> * ~~semicolon~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1059799661
> * ~~stabilization-report~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1033846359
> * ~~summarize-concerns~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1056785904
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383577):
> Shall we stabilize `let else` syntax? We've had many demonstrated uses, including extensively throughout `rust-lang/rust`, we've seen the value of it, and there aren't any known issues with it.

>

> @rfcbot merge

## Active FCPs
### "Enforce Copy bounds for repeat elements while considering lifetimes" rust#95819

**Link:** https://github.com/rust-lang/rust/pull/95819

### "Stabilize `$$` and `${ignore}` in Rust 1.62.0" rust#95860

**Link:** https://github.com/rust-lang/rust/pull/95860

### "Deprecate target_vendor " lang-team#102

**Link:** https://github.com/rust-lang/lang-team/issues/102

### "Positional Associated Types" lang-team#126

**Link:** https://github.com/rust-lang/lang-team/issues/126

### "Interoperability With C++ Destruction Order" lang-team#135

**Link:** https://github.com/rust-lang/lang-team/issues/135

### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

**Link:** https://github.com/rust-lang/lang-team/issues/147

### "Async fns in traits" lang-team#150

**Link:** https://github.com/rust-lang/lang-team/issues/150

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

**Link:** https://github.com/rust-lang/lang-team/issues/160

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "[Experiment] Remove migrate borrowck mode" rust#95565

**Link:** https://github.com/rust-lang/rust/pull/95565

https://github.com/rust-lang/rust/pull/96268 ("Remove mutable_borrow_reservation_conflict lint and allow the code pattern") needs to go in first (currently in FCP), then we should merge 95565.

* There have been some concerns raised from community members about the lack of documentation about this language feature: "How do I teach this? This breaks my mental model of what `&mut` means!"
* joshtriplett made point that two-phase borrows and rvalue-temp-lifetimes both live in this grey area where we have Ph.D-level documentation explaining what the semantics are and why those semantics were selected, but we currently lack high-quality user-oriented documentation for these features that provide the end-user with the right intuition about how these things work.

### "Add attribute to run specific tests in an isolated process" compiler-team#508

**Link:** https://github.com/rust-lang/compiler-team/issues/508

* Consensus amongst participants: we are generally not opposed to work starting here as an unstable feature, though T-lang would expect to be included in an FCP when this feature is eventually put up for stabilization
* towards end of discussion, question was raised: "is this *really* a language change? if so, why? because its an attribute? if not: what is it, libs?"
* this led to subdiscussion of whether this kind of functionality *could* be provided via a procedural macro that rewrote the body of the test.
* that led to further subdiscussion of what that could look like: Reinvoking the original binary and threading through info about which test to run? Or invoking `fork`? (Re `fork` strategy: it was pointed out probably would have all kinds of problems and would not satisfy the use-cases listed here)
* in the end, we did not reach consensus about whether a pure libs implementation was feasible, and that's okay: We can just agree that we'll conservatively treat this as a language feature for now.

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216

**Link:** https://github.com/rust-lang/rfcs/pull/3216

### "Refined trait implementations" rfcs#3245

**Link:** https://github.com/rust-lang/rfcs/pull/3245

### "Allow `impl Fn() -> impl Trait` in return position" rust#93582

**Link:** https://github.com/rust-lang/rust/pull/93582

### "Fix unit struct/enum variant in destructuring assignment" rust#95380

**Link:** https://github.com/rust-lang/rust/pull/95380

### "Neither require nor imply lifetime bounds on opaque type for well formedness" rust#95474

**Link:** https://github.com/rust-lang/rust/pull/95474

### "Modify MIR building to drop repeat expressions with length zero" rust#95953

**Link:** https://github.com/rust-lang/rust/pull/95953

### "nested RPIT and HRTB: unclear semantics and future incompatibility" rust#96194

**Link:** https://github.com/rust-lang/rust/issues/96194

### "Remove label/lifetime shadowing warnings" rust#96296

**Link:** https://github.com/rust-lang/rust/pull/96296

### "Specify guarantees for repr(rust) structs" reference#1152

**Link:** https://github.com/rust-lang/reference/pull/1152

### "Clarify guarantees provided by repr(packed)" reference#1163

**Link:** https://github.com/rust-lang/reference/pull/1163

### "Document the effect of main's return value?" reference#1196

**Link:** https://github.com/rust-lang/reference/issues/1196