---
title: Triage meeting 2022-06-21
tags: triage-meeting
---
# T-lang meeting agenda
* Meeting date: 2022-06-21
## Attendance
* Team members: Josh, Scott
* Others: simulacrum
## Meeting roles
* Action item scribe: simulacrum
* Note-taker: simulacrum
## Announcements or custom items
(Meeting attendees, feel free to add items here!)
## 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
### "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
### "Add const evaluatable `where const { <block> }`" lang-team#163
**Link:** https://github.com/rust-lang/lang-team/issues/163
### "#[repr(Interoperable_2024)]" lang-team#165
**Link:** https://github.com/rust-lang/lang-team/issues/165
* Brief update: Seems to be really invested in a replacement/rewrite for C ABI
* Likely to be left out of scope from Rust driving it
* Josh will communicate to author
## PRs on the lang-team repo
### "Note design constraints on hypothetical `DynSized`" lang-team#166
**Link:** https://github.com/rust-lang/lang-team/pull/166
## RFCs waiting to be merged
None.
## Proposed FCPs
**Check your boxes!**
### "Tracking issue for `IntoFuture`" rust#67644
- **Link:** https://github.com/rust-lang/rust/issues/67644
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/67644#issuecomment-1150164835):
> Team member @yaahc has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Amanieu
> * [x] @BurntSushi
> * [ ] @cramertj
> * [x] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @yaahc
>
> 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/67644#issuecomment-1150164808):
> Fantastic report, thank you
>
> @rfcbot merge
### "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
### "Never allow unwinding from Drop impls" lang-team#97
- **Link:** https://github.com/rust-lang/lang-team/issues/97
- [**Tracking Comment**](https://github.com/rust-lang/lang-team/issues/97#issuecomment-1152706219):
> 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/lang-team/issues/97#issuecomment-1152698760):
> I had previously raised the question of adding documentation for what patterns people should use to allow handling errors when closing a resource. @Amanieu discovered that apparently we have that documentation already: https://rust-lang.github.io/api-guidelines/dependability.html#destructors-never-fail-c-dtor-fail
>
> Given that documentation, I'd like to gauge team consensus on the following narrow question:
>
> Do we want to switch the default over to `panic-in-drop=abort`?
>
> Note that this is *not* yet asking the question of whether we want to remove panic-in-drop=unwind, or add a stable option for it, or any other aspect of this change, only whether we want to switch the default.
>
> @rfcbot merge
* Ongoing discussion, discussed last week in triage
* Desire for an RFC was raised in that meeting -- seems like this is a pending action
* Josh to leave a comment in the thread after the meeting canceling FCP in favor of an RFC, which lays out design, rejected alternatives, etc.
## Active FCPs
### "Refined trait implementations" rfcs#3245
**Link:** https://github.com/rust-lang/rfcs/pull/3245
### "make const_err show up in future breakage reports" rust#97743
**Link:** https://github.com/rust-lang/rust/pull/97743
### "allow unions with mutable references and tuples of allowed types" rust#97995
**Link:** https://github.com/rust-lang/rust/pull/97995
### "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
### "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
### "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
* Process partially broke down here, with a lack of clear message for the proposers about whether this was approved for experimentation/Zulip/git-repo or not;
* this particular proposal is now unblocked
* but we should continue iterate on process & automation.
## P-critical issues
None.
## Nominated RFCs, PRs and issues discussed this meeting
### "New rustc and Cargo options to allow path sanitisation by default" rfcs#3127
**Link:** https://github.com/rust-lang/rfcs/pull/3127
* Primary *possible* interaction is with `file!`
* But the specific details of that behavior is T-libs-api, probably.
* So inclination to drop lang nomination and indicate leaving decisions here elsewhere.
* Josh to post a comment and un-nominate.
### "Tracking Issue for `#[instruction_set]` attribute (RFC 2867)" rust#74727
**Link:** https://github.com/rust-lang/rust/issues/74727
* Felix is formally liaison
* May be good to poke for taking a look and fcp'ing
* Josh to post a comment to that effect
### "Should `repr(transparent)` require *inhabited* 1-ZSTs?" rust#96921
**Link:** https://github.com/rust-lang/rust/issues/96921
* It's not clear whether we will want to break existing code (particularly since e.g. hyper is affected)
* Suggestion to add a lint here linting against this pattern
* Our story around compatibility (e.g., if you use an external crate's ZST in repr(transparent)) is not great today
* We could roll such a lint in to that
* Proposal: unnominate, maybe a lint
### "clarify how Rust atomics correspond to C++ atomics" rust#97516
**Link:** https://github.com/rust-lang/rust/pull/97516
* Josh potentially could investigate here
* Some fairly detailed discussion on the PR
* Current C++ model is also still not entirely solidified; e.g., relaxed and non-relaxed interactions are under some continued debate
* We may eventually iterate to future versions of the C/C++ model or otherwise "iterate", closing the gaps here
### "allow unions with mutable references and tuples of allowed types" rust#97995
**Link:** https://github.com/rust-lang/rust/pull/97995
* No longer nominated; exiting FCP soon.
### "Document the effect of main's return value?" reference#1196
**Link:** https://github.com/rust-lang/reference/issues/1196
* Dropping nomination; this looks done from the lang side at least. Maybe could be closed, but leaving that open.
### "Specify what happens when casting fat pointers more specifically" reference#1206
**Link:** https://github.com/rust-lang/reference/pull/1206
```
*const [u32] as *const [u8] // same length of slice, but completely different memory
```
Adding an example for the "length of slice" behavior would be a good idea.
### "Always create elided lifetime parameters for functions" rust#97720
**Link:** https://github.com/rust-lang/rust/pull/97720
* Not clear why this is necessary to land as immediately stable
* No obvious objections to the feature itself, though