---
title: Triage meeting 2022-05-31
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-05-31

## Attendance

* Team members: pnkfelix, joshtriplett
* Others: simulacrum

## Meeting roles

* Action item scribe: simulacrum
* Note-taker: pnkfelix

## Additional agenda items

- Kangrejos - Rust in Linux conference (workshop/summit), in Spain in mid-August (after RustConf)
- planned in-person; no known plan to support hybrid for this specific event

- Unwinding from Drop impl
- Amanieu seeking next steps on this
- Rough consensus: we need a clear story for what should be done by applications that want to never stop (e.g. web servers catching panics within requests and returning 500 Internal Server Error)

- cfg_accessible being worked on
- https://github.com/rust-lang/rust/pull/97391
- May allow unblocking cfg_accessible
- Discussion of certain implementation details, relating to trying to use feature in current-crate
- Josh points out that the main use-case for this feature is for conditionalizing on accessibilty from *other crates*, so we would be happy if this feature simply errored out with "not supported" if you tried to apply it to something in the current crate.

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

## Active FCPs
### "Lang: Stabilize usage of rustc_nonnull_optimization_guaranteed on -1" rust#97122

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

- scottmcm: Where are these types exposed?
- `std::os::unix::io`

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

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

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

* CAD97 had some concerns
* CAD97 pointed out that josh themself [got the syntax wrong](https://github.com/rust-lang/rust/pull/95860#issuecomment-1139881538) when interacting on issue; this gave them pause: Is this a sign that the syntax is itself overly confusing?
* scottmcm is not sure we should read too much into that
* (the specific concern is the use of `$op(var)` rather than `$op($var)`, since the latter is what many will expect): conflicting mental models of "`$var` is how you name a metavariable" versus "`$var` is the expansion of the metavariable var."
* scottmcm: will we ever want random tokens in the input to `$ignore(..)`, or is it always going to be restricted to just metavariables?
* scottmcm: should we ask a libs expert about this?
* josh: why would this be a libs matter?
* scottmcm: "libs" is a placeholder for "person who writes macros a lot"; e.g. dtolnay.
* scottmcm: but maybe such people aready weighed in on the RFC?
* simulacrum: was the alternative discussed on the RFC?
* josh: don't think so
* simulacrum: requiring the dollar sign would be backwards compatible with allowing it to be dropped.
* josh: the real point is that its an error to include the dollar sign in the first place
* pnkfelix: it comes down to that CAD97 question of what the right mental model is: "`$var` is how you name a metavariable" versus "`$var` is the expansion of the metavariable var."
* pnkfelix: and this sets a precedent, right? This is the first time we're adding this kind of meta-operation.
* josh: could support both options
* scottmcm: or we could add the second option when we have another meta-operation that would motivate such support.
* simulacrum: for now I would suggest changing to requiring `$var` now and not try to accept the other. It seems like the easier way to start, to force people to write the `$` and then if we can justify taking it out later, that will be an easier shift to make.
* pnkfelix: so what would we want if we *were* trying to also adopt the other meta operations like `$count(..)`, `$index(..)`, ...
* https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md#guide-level-explanation
* josh: do we think we (subset of T-lang) can actually make a decision in *this* meeting? or should we raise a concern and resolve the matter asynchronously?
* pnkfelix: lets raise a concern.

### “Warn about dead tuple struct fields” rust#95977

Link: https://github.com/rust-lang/rust/pull/95977

- Do we have a migration plan?
- Josh: labeled relnotes, we should mention it in release notes and wait a few releases
- Mark: Should this special case PhantomData? (Mark to post a comment.)

### "Stabilize `let_chains` in Rust 1.63.0" rust#94927

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

* With this, `let x = ...` now gets treated as an expression in terms of how macro expression parsing works.
* https://github.com/rust-lang/rust/pull/97295
* josh: if being conservative in this case is as simple as PR 97295, then I'm going to register that my concern is indeed blocking on landing PR #97295 first.

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "Covariance-related GAT lifetime mismatch" rust#89352

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

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

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

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

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