---
# System prepended metadata

title: Triage meeting 2022-06-21
tags: [triage-meeting]

---

---
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



