---
title: Triage meeting 2023-06-27
tags: triage-meeting, T-lang
date: 2023-06-27
url: https://hackmd.io/hTUmwMrbSSqN1eU2k90Iwg
---

# T-lang meeting agenda

* Meeting date: 2023-06-27

## Attendance

* Team members: Josh, Tyler
* Others: TC, Lokathor, David

## Meeting roles

* Action item scribe:
* Note-taker: Lokathor

## Scheduled meetings
- "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, take 2 (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:

// Example A.
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:

// Example C.
type Foo = impl Sized;

mod foo {
    fn bar() -> Foo { () } // Legal.
}

#### Sneaky inner impls in Rust

Consider this code that stable Rust allows today:

// Example B.
trait Trait {}
struct S;
fn foo() {
    impl Trait for S {}
}

The `impl` within function body of `foo` affects the broader scope. We could say that it does this "sneakily" because it does so without mentioning anything about what it plans to affect in its signature.

Likewise, without the nested inner function restriction, we could say the same about `foo` in Example A above.

#### Why is this a problem?

As long as either Example A or Example B are legal in Rust, tools such as rust-analyzer must parse all function bodies to be sure that they have correctly inferred any type. The authors of these tools would prefer that this were not necessary as that could enable better performance while achieving correct behavior.

#### How might this be addressed?

There is a [draft proposal][restrict-sneaky] that would make these sneaky inner impls illegal in a future edition of Rust. If that proposal were adopted, then it would be logical for the nested inner function restriction to apply to TAIT.

#### What has @matklad said about this?

Regarding these sneaky inner impls, why they are an issue, and what to do about them, @matklad has [said](https://github.com/rust-lang/rfcs/pull/3373#issuecomment-1406888432):

> I guess my overall thrust here is that, if we do this, its important to do 100% of it. We don't want to forbid this because it's an unreadable mess: no need to forbid something which isn't used anywhere outside of dtolnay's famous quiz. We want to forbid this, because we want to make the implementation faster. In some future edition, we want to just [throw] every function onto a threadpool and typecheck the world on all cores, without any synchronization. If there's at least one case where we need to invalidate typechcking results of `foo` when we learned something new when checking `bar`, this optimization simply doesn't work.

The authors have confirmed with @matklad that Example A above is the same problem as the other sneaky impls and that his statement applies to this case as well.

#### What decision do we have to make?

If we were sure that we were going to adopt the [draft proposal][restrict-sneaky] to restrict sneaky impls in the next edition, then it might make sense to adopt the nested inner function restriction with the TAIT stabilization to avoid adding a new case that must be addressed over an edition. On the other hand, even if we were planning to adopt that proposal, we could take the view that it might still be more consistent to simply allow this in this edition and restrict it when the other cases are restricted. This may be even more true if we're not sure that we will in fact adopt the proposal, or if we're not sure that we will adopt it for the 2024 edition.

[restrict-sneaky]: https://github.com/rust-lang/rfcs/pull/3373

---

Action item from last week was to check with rust-analyzer, which is now done.

RA people aren't worried about Example C. 90% of code is in fn bodies, so they don't want to parse them. Inner modules are "fine" for them.

Tyler: I thought this was more for humans rather than tools. If so, we should also restrict modules.

TC: using nested inner modules can prevent cycle errors, and thus is a desirable ability. Rust *tells* people to use inner modules to avoid these errors.

Tyler: Unfortunate we have to make this work-around

TC: The RFC had no restrictions about cycle errors or signatures

TC: this all goes back to leaked auto-traits: within a fn body where you are not constraining the hidden type, but you could be, and haven't type checked yet, you need to know if a hidden type impls an auto-trait. If you need to make that check (send/sync) the type checker can get into a cycle if its own type depends on the hidden type because of auto-traits. Currently: the compiler errors as often as possible to allow options for future changes which would error less.

Tyler: I think I need to see some examples of the types of errors here.

Tyler: Can we handle inner fns and inner modules separately?

*discussion*

Lokathor: So is allowing the modules issue just a code style difference? I use inner modules to allow more editor tabs and then only fix the visibility up at the crate level.

Josh: So how can we resolve this?

TC: If we accept [3373](https://github.com/rust-lang/rfcs/pull/3373) then preventing inner items should be handled.

Tyler: Seems fine. There was a separate concern about defining through encapsulation

TC: That would have to be a separate call.

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals

None.

## PRs on the lang-team repo
### "Expand variadic generics design notes" lang-team#212

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

not discussed, but please read the PR and comment if necessary

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

deferred

### "feat: split `unsafe_code` lint into lint group" rust#108975

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

This is in FCP, so it should be un-nominated

### "Create `unnecessary_send_constraint` lint for `&(dyn ... + Send)`" rust#110961

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

instructive notes from the PR thread: <https://github.com/rust-lang/rust/pull/110961#issuecomment-1528813797>

Mara's latest explanation: <https://github.com/rust-lang/rust/pull/110961#issuecomment-1550271436>

Seems to make sense, FCP started.

### "Support interpolated block for `try` and `async`" rust#112953

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

Lokathor: I don't know why this *doesn't* work for unsafe

Josh: Historical accident perhaps. Proposal: FCP to merge, and also ping lang-advisors for any historical info about why `unsafe` is different.

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

skipped

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

waiting on author

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

waiting on niko

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

waiting on CAD97

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

waiting on author

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

discussed in the first half of the meeting

### "feat: split `unsafe_code` lint into lint group" rust#108975

- **Link:** https://github.com/rust-lang/rust/pull/108975
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108975#issuecomment-1599279387):
> Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @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/108975#issuecomment-1599279361):
> Based on Scott's analysis:
>
> @rfcbot close

in fcp close already

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

TC: niko raised concern because proposer of the PR pointed out an error in the reasoning for FCP Close. This isn't a "you could write this better" situation, this is "always a bug".

Josh: should we cancel the FCP Close and move to do an FCP Merge instead?

TC + Tyler: There can be false positives

Josh + Lokathor: the bar for a lint (rather than an error) isn't "no false positives", it only needs to be a very very low rate of false positives.

### "make `noop_method_call` warn by default" rust#111916

- **Link:** https://github.com/rust-lang/rust/pull/111916
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/111916#issuecomment-1599418260):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @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/111916#issuecomment-1599418200):
> @rfcbot fcp merge
>
> From the random things I checked in the crater run, this looks like it'll be a great warning to have on-by-default.

## Active FCPs
### "Add `internal_features` lint" rust#108955

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

### "Don't require associated types with Self: Sized bounds in `dyn Trait` objects" rust#112319

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

(none yet, move things from the section below as they are discussed)

### "Clearly specify the `instruction_set` inlining restrictions" reference#1307

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

Amaneau commented the info requested last meeting: https://github.com/rust-lang/reference/pull/1307#issuecomment-1599343290

Josh: What Amaneau says is correct and should be in the reference. some info is better than no info. We should do some now and we can do more later.

Lokathor: I will update the PR and then we can do an FCP

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

### "dyn Trait comparison should not include the vtable pointer" rust#106447

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

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

### "Shorten drop scope of temporaries in conditions" 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

### "let-else does not support `else if`" rust#111910

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

### "make `noop_method_call` warn by default" rust#111916

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

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

### "add wrapping_offset_from which allows wrapping but still requires ptrs to be for the same allocation" rust#112837

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

### "Support interpolated block for `try` and `async`" rust#112953

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

### "Does T-lang have opinion on floating-point guarantees?" lang-team#210

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