---
title: Triage meeting 2023-03-14
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-03-14

## Attendance

* Team members:
* Others:

## Meeting roles

* Action item scribe:
* Note-taker:

## Scheduled meetings

### TOMORROW

- "Temporary lifetimes" [lang-team#197](https://github.com/rust-lang/lang-team/issues/197)

### LATER

- "Language design principles" [lang-team#189](https://github.com/rust-lang/lang-team/issues/189)
- "Design decisions around the `#[expect]` attribute" [lang-team#191](https://github.com/rust-lang/lang-team/issues/191)
- "discuss/resolve `fn { mod { (use) super::...; } }` and its interaction with derive patterns" [lang-team#193](https://github.com/rust-lang/lang-team/issues/193)
- "Design Meeting: Field Projection" [lang-team#194](https://github.com/rust-lang/lang-team/issues/194)
- "Interface between opsem and lang team" [lang-team#196](https://github.com/rust-lang/lang-team/issues/196)

## Announcements or custom items

### Async traits MVP

### TAITs decision point

* Restricted version implemented:
* https://github.com/rust-lang/rust/pull/107809

One edge case doesn't work as I liked, but it's backwards compatible to fix

type TAIT = impl Debug;
impl Iterator<T> for Foo {
    type Item = u32;
    fn next(&mut self) -> Option<<Foo as Iterator<TAIT>>::Item> {
        //                                        ^^^^
        //   it appears here, but after normalization this is invisible
        //   to compiler, so you get an error here
        
        let x: TAIT = 22_u32; // constrain
    }
}

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

## Proposed FCPs

**Check your boxes!**
### "Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods" rfcs#3240

- **Link:** https://github.com/rust-lang/rfcs/pull/3240
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3240#issuecomment-1377748067):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Amanieu
> * [ ] @BurntSushi
> * [ ] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @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/rfcs/pull/3240#issuecomment-1377748031):
> @rfcbot merge

### "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
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
>
> 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: result_ffi_guarantees" rfcs#3391

- **Link:** https://github.com/rust-lang/rfcs/pull/3391
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3391#issuecomment-1448763059):
> 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
> * [x] @tmandry
>
> Concerns:
>
> * ~~needs-to-mention-non_exhaustive~~ resolved by https://github.com/rust-lang/rfcs/pull/3391#issuecomment-1458683510
>
> 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/3391#issuecomment-1448763007):
> @rfcbot merge

### "Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc)" rust#51540

- **Link:** https://github.com/rust-lang/rust/issues/51540
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/51540#issuecomment-1448404177):
> Team member @Amanieu has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @BurntSushi
> * [x] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @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/issues/51540#issuecomment-1448404145):
> After working on the OOM handler for a while, I think that the best way to move forward is to just treat OOM as a normal panic (so that it calls the normal panic handler/hooks). This is what already happens on `#![no_std]` since https://github.com/rust-lang/rust/pull/102318 was merged.
>
> I believe that we should do the same for the `std` case. Specifically:
> - The unstable `#[alloc_error_handler]` is removed. `alloc::alloc::handle_alloc_error` now always invokes the panic handler.
> - For backwards compatibility reasons, this is a [non-unwinding](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.can_unwind) panic. Unsafe code may not be written to correctly handling unwinding out of a memory allocation (this is in fact a frequent source of bugs in C++!). However this behavior can be overridden with `-Zoom=panic` which changes the behavior to a normal unwinding panic.
> - Since there is no separate handling for OOM any more, the unstable [OOM hook API](https://github.com/rust-lang/rust/issues/51245) in the standard library can also be removed.
>
> @rfcbot fcp close

### "Tracking issue for RFC 2515, "Permit impl Trait in type aliases"" rust#63063

- **Link:** https://github.com/rust-lang/rust/issues/63063
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/63063#issuecomment-1360043090):
> Team member @nikomatsakis 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
> * [ ] @scottmcm
>
> Concerns:
>
> * ~~~~ resolved by https://github.com/rust-lang/rust/issues/63063#issuecomment-1361432898
> * docs (https://github.com/rust-lang/rust/issues/63063#issuecomment-1364525286)
> * function-defining-uses (https://github.com/rust-lang/rust/issues/63063#issuecomment-1385946789)
>
> 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/63063#issuecomment-1360043060):
> @rfcbot fcp merge
>
> This has been a long-time coming. Let's Do This!
>
> [Stabilization report in this comment.](https://github.com/rust-lang/rust/issues/63063#issuecomment-1354392317)

### "Tracking Issue for "C-unwind ABI", RFC 2945" rust#74990

- **Link:** https://github.com/rust-lang/rust/issues/74990
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/74990#issuecomment-1363474839):
> 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
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * docs (https://github.com/rust-lang/rust/issues/74990#issuecomment-1364528477)
>
> 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/74990#issuecomment-1363474832):
> Shall we stabilize the `extern "C-unwind"` and other `-unwind` calling conventions? This change will leave `extern "C"` unchanged for now, but have the existing feature gate continue to opt into the new behavior on nightly. We'll do a separate change later to make `extern "C"` and similar not permit unwinding.
>
> @rfcbot merge

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

### "Clarify stability guarantee for lifetimes in enum discriminants" rust#104299

- **Link:** https://github.com/rust-lang/rust/pull/104299
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104299#issuecomment-1451325906):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [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/104299#issuecomment-1451325893):
> @rfcbot fcp merge
>
> This PR documents that the discriminants of enums that are generic over a lifetime do not change when only the concrete value of the lifetime changes.
>
> It does look related to the decision in https://github.com/rust-lang/rust/pull/101520, but that was about transmutes, and this is about the value of enum discriminants.
>
> I don't see how we could sensibly do anything different here, so I think we should go ahead and document this.

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

### "Add a builtin `FnPtr` trait that is implemented for all function pointers" rust#108080

- **Link:** https://github.com/rust-lang/rust/pull/108080
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108080#issuecomment-1457830765):
> Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @compiler-errors
> * [ ] @cuviper
> * [ ] @jackh726
> * [ ] @joshtriplett
> * [x] @lcnr
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [x] @oli-obk
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @spastorino
> * [ ] @the8472
> * [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/108080#issuecomment-1457830730):
> This PR adds a `FnPtr` trait that is implemented for *all* function pointers (even `unsafe` ones, `extern` ones, higher kinded ones or ones with more than 12 args). This allows us to implement various traits (like `PartialEq` or `Debug`) in terms of that `FnPtr` trait (it exposes a method for returning the address the pointer points to). This reduces the `((12 + 1) * 12 / 2 * 10 - 4) * 7` (`776 * 7`) macro generated impls we have right now to `7` blanket impls for `T` where `T: FnPtr`.
>
> Blanket impls have the issue that they'll report that a type does not implement `Debug` because it does not implement `FnPtr`, because rustc always assumes the blanket impl is the right one if there is no other one. It's obviously nonsense to report that e.g. `Mutex` does not implement `FnPtr`. So we added a quick reject in trait resolution to avoid considering these blanket impls unless the self type implements `FnPtr` (either by being a function pointer or by being a type parameter with a `FnPtr` bound).
>
> The `FnPtr` trait is *not* stable, but this PR insta-stabilizes all of
>
> * `PartialEq`
> * `Eq`
> * `PartialOrd`
> * `Ord`
> * `Hash`
> * `fmt::Pointer`
> * `Debug`
>
> for all function pointer types.
>
> An alternative design would be to add some magic syntax (e.g. a builtin macro) that expands directly to a `ty::FnPtr` internally which has all its possible variants be generic. That would avoid the blanket impl issues, but makes the type system more complex, while the scheme of this PR works with something we already do regularly: add built-in trait impls for types automatically within the trait solver.
>
>
> @rfcbot merge

## Active FCPs
### "Lint ambiguous glob re-exports" rust#107880

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Introduce terminating scope for tail expressions of breakable scopes" rust#106493

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

nikomatsakis: I'm inclined to close this and we can discuss options in the meeting tomorrow.

### "Clarify that free constants are always evaluated at compile time" reference#1328

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

Example:

// Compile-time panic
const PANIC: () = std::unimplemented!();
fn unused_generic_function<T>() {
    // A failing compile-time assertion
    const _: () = assert!(usize::BITS == 0);
}

Meeting consensus: looks good.

### "Relax ordering rules for `asm!` operands" reference#1323

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

### "Make late_bound_lifetime_arguments a hard error." rust#108782

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

Conclusion: fcp merge

### "The `#[diagnostic]` attribute namespace" rfcs#3368

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

Concerns:

* nikomatsakis:
* I'd like to separate the details of "on-unimplemented" from the diagnostic mechanism.
* scottmcm:
* How much is this language vs compiler? Trying to figure out how we say that something is "RFC'd by language but up to compiler to know what to do with it".
* What exactly *is* a new version? Writing out the behavior for this error message is complicated?
* nikomatsakis:
* want a way to steer diagnostics, and want that to be portable across implementations
* I'd expect to say that we will specify the arguments that are expected and roughly what they mean, but which doesn't necessarily specify an exact formula for when things trigger
* scottmcm: would we expect future RFCs, e.g. for do-not-recommend?
* nikomatsakis: I think so, I think designating a space still has value, and the versioning mechanism
* simulacrum: note this is a novel versioning mechanism
* nikomatsakis: I do feel I would rather leverage editions
* simulacrum: rationale is that on-unimplemented etc will change much more rapidly
* goal is to have a user-space, non-compiler library, e.g. on crates.io, which will detect which version of rustc you're using and transpile the diesel attribute into something compatible and targeting that specific version of rustc
* nikomatsakis: I think we should have a design meeting, it seems like what's being really RFC'd here is the workflow by which crates will tailor their error messages; not sure about that story.

### "Lint ambiguous glob re-exports" rust#107880

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

Un-nominating, in FCP.

### "RFC: Postfix match" rfcs#3295

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

*People in meeting seemed generally positive, fcp merge?*

### "Evaluate place expression in `PlaceMention`" rust#104844

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

### "Add a builtin `FnPtr` trait that is implemented for all function pointers" rust#108080

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

impl<T> Foo for fn(T)

impl<T> Foo for for<'a> fn(&'a T)

Today:

fn is<T: std::fmt::Debug>() { }

fn main() {
    is::<fn(u8)>(); // OK
    is::<fn(&u8)>(); // ERROR
}

### "`overflowing_literals` should have an option for "ignore signed overflows"" rust#99195

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

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

### "unsafe attributes" rfcs#3325

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

### "RFC: Start working on a Rust specification" rfcs#3355

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

### "TAIT defining scope options" rust#107645

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

### " Make typeck aware of uninhabited types" rust#108993

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