---
title: Triage meeting 2023-06-20
tags: triage-meeting
---
# T-lang meeting agenda
* Meeting date: 2023-06-20
## Attendance
* Team members: Josh, Scott
* Others: David, Lokathor, TC
## Meeting roles
* Action item scribe:
* Note-taker:
## Scheduled meetings
- "Keyword Generics Initiative Update" [#203](https://github.com/rust-lang/lang-team/issues/203)
- "Language design principles" [#189](https://github.com/rust-lang/lang-team/issues/189)
- "Rust 2024 survey" [#209](https://github.com/rust-lang/lang-team/issues/209)
Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.
## Announcements or custom items
(Meeting attendees, feel free to add items here!)
### TAIT nested inner functions restriction (TC)
In the design meeting for TAIT, we had proposed a restriction that forbid nested inner functions from constraining a hidden type unless the hidden type was in the signature of the parent function. For example:
```rust
type Foo = impl Sized;
fn foo() {
fn bar() -> Foo { () } // Illegal under original proposal.
}
```
However, @tmandry has raised a concern that this restriction feels surprising and inconsistent in light of the rule that allows child modules to constrain the hidden type. For example:
```rust
type Foo = impl Sized;
mod foo {
fn bar() -> Foo { () } // Legal.
}
```
Oli and I agree with this concern. Neither of us feels strongly about defending this restriction. Removing this restriction raises zero implementation concerns.
We propose to remove the restriction. I raise the issue in this meeting to confirm that there is consensus for this minor tweak.
## Action item review
* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)
## Pending lang team project proposals
None.
## PRs on the lang-team repo
None.
## RFCs waiting to be merged
None.
## `S-waiting-on-team`
### "Tracking issue for dyn upcasting coercion" rust#65991
**Link:** https://github.com/rust-lang/rust/issues/65991
### "feat: split `unsafe_code` lint into lint group" rust#108975
**Link:** https://github.com/rust-lang/rust/pull/108975
## Proposed FCPs
**Check your boxes!**
### "unsafe attributes" rfcs#3325
- **Link:** https://github.com/rust-lang/rfcs/pull/3325
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911253):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * ~~change-syntax-to-drop-parentheses~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974
> * ~~maybe-make-this-part-of-next-edition~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458690311
> * syntax-not-ideal (https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/3325#issuecomment-1396911218):
> @rfcbot merge
### "RFC: UTF-8 characters and escape codes in (byte) string literals" rfcs#3349
- **Link:** https://github.com/rust-lang/rfcs/pull/3349
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747916):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
> * waiting-on-update-re-using-char-and-string-tables (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1503875165)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/3349#issuecomment-1396747889):
> I do think we should permit `br"¥¥¥"`, but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.
>
> I'm going to go ahead and propose FCP for this. This does *not* preclude making further changes to how this information is presented.
>
> @rfcbot merge
>
> @rfcbot concern raw-byte-strings-with-unicode
### "RFC: Start working on a Rust specification" rfcs#3355
- **Link:** https://github.com/rust-lang/rfcs/pull/3355
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1513641410):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * naming (https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1587572543)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/3355#issuecomment-1513641387):
> @rfcbot fcp merge
>
> We talked about this in the lang team triage meeting and agreed that this is ultimately a council-level decision. That said, it seems like a good idea to get formal lang team buy-in ahead of the council making a decision on this.
>
> Since we can do that now while the council is still forming, I'm opening an FCP for it. **Note that this will still need a _separate_ FCP to actually be merged once the governance council is formed.**
### "Stabilise inline_const" rust#104087
- **Link:** https://github.com/rust-lang/rust/pull/104087
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231887):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * ~~expectations-around-panics-in-inline-const~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210
> * optimization-dependent-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210)
> * ~~post-monomorphization-errors~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1448730779
> * should-unused-code-cause-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1410921524)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/104087#issuecomment-1350231871):
> Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
>
> @rfcbot fcp merge
### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378
- **Link:** https://github.com/rust-lang/rust/pull/107378
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287200):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
> * why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/107378#issuecomment-1430287177):
> We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:
>
> @rfcbot merge
>
> We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.
### "TAIT defining scope options" rust#107645
- **Link:** https://github.com/rust-lang/rust/issues/107645
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789843):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * encapsulation-is-too-powerful (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
> * nested-modules-can-always-define-but-nested-functions-cannot (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/107645#issuecomment-1571789814):
> @rfcbot fcp merge
>
> We held a design meeting yesterday where we reviewed [this document](https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2023-05-31-TAIT-stabilization.md) prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.
>
> The document proposed the following resolution to this issue:
>
> - The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
> - Functions and methods must have the hidden type that they intend to constrain within their signature -- within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
> - Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
> - A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
> - The hidden type may be constrained by functions, methods, constants, and statics.
>
> The doc goes into more detail about the justifications and alternatives.
>
> Given all this, I propose to merge and accept this proposal.
### "Add `internal_features` lint" rust#108955
- **Link:** https://github.com/rust-lang/rust/pull/108955
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108955#issuecomment-1564739018):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * does-this-now-need-a-compiler-team-fcp-as-well (https://github.com/rust-lang/rust/pull/108955#issuecomment-1592023698)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/108955#issuecomment-1564739001):
> I was pondering whether this is more lang or more compiler, but with a compiler MCP already complete,
>
> @rfcbot fcp merge
>
> I support giving stronger discouragement from using `S-tracking-perma-unstable` things.
>
### "Uplift `clippy::option_env_unwrap` lint" rust#111738
- **Link:** https://github.com/rust-lang/rust/pull/111738
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/111738#issuecomment-1559994605):
> Team member @nikomatsakis has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * move-errors-left (https://github.com/rust-lang/rust/pull/111738#issuecomment-1564194388)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/111738#issuecomment-1559994585):
> @rfcbot fcp close
>
> We discussed this in the lang-team meeting and felt it did not meet the rustc bar of preventing bugs or helping to shape ecosystem wide consistency (like naming conventions).
>
> We would be interested in some kind of "custom lint" mechanism. Ideally this would be a pattern-matching scheme that would ecosystem crates provide this sort of lint. A more limited thing might be something like #[must_use] (e.g., #[prefer_on_unwrap("env!")], but some members of the team were skeptical of such a narrow purpose attribute. Regardless that would be a separate proposal that would ultimately require an RFC.
>
> The motivation here is that we think "usage lints" like this add value, but to do so, you need an awful lot of them, and we think the best way to get that is to let people add them themselves. Otherwise, clippy is a better home.
### "Don't require associated types with Self: Sized bounds in `dyn Trait` objects" rust#112319
- **Link:** https://github.com/rust-lang/rust/pull/112319
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/112319#issuecomment-1592574451):
> Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @BoxyUwU
> * [x] @aliemjay
> * [x] @compiler-errors
> * [x] @jackh726
> * [ ] @joshtriplett
> * [x] @lcnr
> * [x] @nikomatsakis
> * [x] @oli-obk
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @spastorino
> * [x] @tmandry
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/112319#issuecomment-1592574418):
> @rfcbot fcp merge
>
> I am starting this FCP for both T-types and T-lang. While I believe closing such gaps is entirely in the purview of T-types, considering that I want to close further such gaps, I would like T-lang to chime in to say whether they agree with my assessment and are fine with just getting pinged in the future, but not included in the FCPs.
>
> The summary of what is being stabilized here is all documented in the main post.
## Active FCPs
### "Tracking issue for RFC 1868: A portability lint" rust#41619
**Link:** https://github.com/rust-lang/rust/issues/41619
## P-critical issues
None.
## Nominated RFCs, PRs and issues discussed this meeting
### "let-else does not support `else if`" rust#111910
**Link:** https://github.com/rust-lang/rust/issues/111910
Some discussion, but not enough team members present to get a clear consensus on dispositioning. Will return to it later. Josh and/or Scott to post comments and discuss async.
### "Clearly specify the `instruction_set` inlining restrictions" reference#1307
**Link:** https://github.com/rust-lang/reference/pull/1307
Amanieu to post a comment.
### "dyn Trait comparison should not include the vtable pointer" rust#106447
**Link:** https://github.com/rust-lang/rust/issues/106447
Current state: team doesn't have consensus on the path forward, though agrees that the current behavior probably isn't right.
### "make `noop_method_call` warn by default" rust#111916
**Link:** https://github.com/rust-lang/rust/pull/111916
We asked for a summary of the crater results, and got one. No apparent false positives.
## Nominated RFCs, PRs and issues NOT discussed this meeting
### "RFC: Start working on a Rust specification" rfcs#3355
**Link:** https://github.com/rust-lang/rfcs/pull/3355
### "Explicit Tail Calls" rfcs#3407
**Link:** https://github.com/rust-lang/rfcs/pull/3407
### "feat: split `unsafe_code` lint into lint group" rust#108975
**Link:** https://github.com/rust-lang/rust/pull/108975
### "Make pointer_structural_match normal and warn" rust#110166
**Link:** https://github.com/rust-lang/rust/pull/110166
### "Create `unnecessary_send_constraint` lint for `&(dyn ... + Send)`" rust#110961
**Link:** https://github.com/rust-lang/rust/pull/110961
### "optimizing Use expressions inside if condition (take 2)" rust#111725
**Link:** https://github.com/rust-lang/rust/pull/111725
### "Uplift `clippy::option_env_unwrap` lint" rust#111738
**Link:** https://github.com/rust-lang/rust/pull/111738
### "RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods" rust#112194
**Link:** https://github.com/rust-lang/rust/issues/112194
### "Should associated type bounds on supertraits be implied?" rust#112573
**Link:** https://github.com/rust-lang/rust/issues/112573
### "Does T-lang have opinion on floating-point guarantees?" lang-team#210
**Link:** https://github.com/rust-lang/lang-team/issues/210
Sign in with Wallet
Connect another wallet