---
title: Triage meeting 2022-06-07
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-06-07

## Attendance

* Team members: Josh, Felix, ½Scott
* Others: Mark, Urgau

## Meeting roles

* Action item scribe:
* Note-taker: pnkfelix

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

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Refined trait implementations" rfcs#3245

- **Link:** https://github.com/rust-lang/rfcs/pull/3245
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3245#issuecomment-1116370994):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * unresolved-question-for-next-edition (https://github.com/rust-lang/rfcs/pull/3245#issuecomment-1116371336)
>
> 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/rfcs/pull/3245#issuecomment-1116370985):
> @rfcbot fcp merge^M
> ^M
> I think we've got consensus on most of this here -- the main question is whether, in the next edition, `#[refine]` ought to be required in order to see the effects of the change or optional (perhaps with a lint). I'm going to separate propose a concern to move this to an unresolved question, I dont' see why it should block this RFC from going forward now.

### "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.^M
> ^M
> @rfcbot merge

### "make cenum_impl_drop_cast deny-by-default" rust#97652

- **Link:** https://github.com/rust-lang/rust/pull/97652
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/97652#issuecomment-1145151460):
> 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
> * [x] @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/pull/97652#issuecomment-1145151443):
> @rfcbot merge

* no objections raised to the plan (promote from warn to deny-by-default, with plan for eventual hard error)

## Active FCPs
### "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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Expand the Rust Bookshelf 📚" rust#49453

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

* semi-random list of links; would be better/more actionable if these were rephrased in terms of individual proposed documents to merge
* there is an unresolved policy question: Do we really want to link from the "Rust Bookshelf" to a document that is hosted outside of the project space?
* josh reviewed the list and determined some have already been promoted to "official" status hosted within the project, while others are only within the nursery (and not touched in a year) and others are only hosted by an individual
* proposal: Easy Policy is to link to first-party resources under rust-lang/ control. That would lead to proposing links to "Rust API guidelines", and we would also query the "Asynchronous Programming in Rust" authors to find out if they think it is ready to be linked from the bookshelf.
* so: close PR #49453, with comment saying "if you want to add a link to something already under rust-lang, go ahead and submit a PR to the docs"
* and if you want to link to something that is *not* under rust-lang, then find a team to adopt the work officially.
* We are not "officially" saying we would never link to a third-party resource from the bookshelf. Rather, we are acknowledging that the task outlined here was correctly categorized as E-hard, and that was back when we *had* an official docs team (a role that is now collectively shared amongst T-compiler, T-lang, T-libs, ...)
* so, if we *were* to officially link to a third-party resource, we would want to first establish some ground rules: Is this link going to remain forever? Is it served somewhere that can handle the traffic? How is it going to be kept up-to-date? et cetera. *If* all those questions were resolved, then we would be in a better spot to approve such linking to a third-party resource
* Yet another option would be a sticky note on users.rlo or another social site.

### "RFC3239: Implement `cfg(target)` - Part 1" rust#96909

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

* The RFC provides both a `cfg(target = "...")` portion and a `cfg(target(COMP = "...", ...))` where `COMP` is one of the components `os`, `arch`, `vendor`, `env`, `abi`.
* The above PR 96909 only implemented the first part of that, `cfg(target = "...")`, and was met with heavy skepticism as to the value of the feature as described, especially since `cfg_accesible` has become more functionally complete, which covers some of the cases that were otherwise motivating the original `cfg(target = "...")`.
* so now we ask: Should we backtrack here, and revise the RFC to say that we're not going to move ahead with `cfg(target = "...")`
* (discussion ensues about what kind of message this sends, in terms of backtracking on an accepted RFC, with a implementing PR waiting to land, and not even giving the feature a chance to be evaluated. But in this case the PR author appears to be aligned with the feedback stating that the feature may be more problematic than its worth.)
* https://github.com/rust-lang/rust/pull/96913 for the shorthand

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

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

* there are semi-compelling arguments in favor of `${ignore($var)}` rather than `${ignore(var)}`
* there is work progressing on merging a PR that stabilizes *solely* `$$` on its own.
*

${assign($concatted, ${concat($x _foo_ $y)})}

${assign(concatted, ${concat($x _foo_ $y)})}

${assign($$$var_to_assign_to, ...)}

x $x y $y ${assign(concatted, concat(x, quote!(_foo_), y)})}

// procedural invocation form
${first_item()} 

$ignore(xyz)

## Nominated RFCs, PRs and issues NOT discussed this meeting

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

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

### "Change enum->int casts to not go through MIR casts." rust#96862

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

### "Should `repr(transparent)` require *inhabited* 1-ZSTs?" rust#96921

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

### "clarify how Rust atomics correspond to C++ atomics" rust#97516

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

### "Always create elided lifetime parameters for functions" rust#97720

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

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

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

### "Specify what happens when casting fat pointers more specifically" reference#1206

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