---
# System prepended metadata

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

---

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




