---
title: Triage meeting 2024-07-03
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2024-07-03
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202024-07-03
url: https://hackmd.io/TpvcFSJoRhGdydaakNXcZg
---

# T-lang meeting agenda

- Meeting date: 2024-07-03

## Attendance

Meeting part 1:

- People: TC, tmandry, Josh, nikomatsakis, Eric Holk, Santiago, Xiang, CE, Urgau, Amanieu

Meeting part 2:

- People: TC, Josh, tmandry, Eric Holk, Xiang, Vikas Gupta, Dow Street

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2024-07-03: "Design meeting: Extended triage 2024-07-03" [#272](https://github.com/rust-lang/lang-team/issues/272)
- 2024-07-10: "Design meeting: Discriminant syntax (RFC 3607)" [#275](https://github.com/rust-lang/lang-team/issues/275)
- 2024-07-17: "Design meeting: Float semantics (RFC 3514)" [#273](https://github.com/rust-lang/lang-team/issues/273)
- 2024-07-24: "Design meeting: `Freeze` in bounds (RFC 3633)" [#277](https://github.com/rust-lang/lang-team/issues/277)
- 2024-07-31: "Planning meeting: 2024-07-31" [#276](https://github.com/rust-lang/lang-team/issues/276)

Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.

## Announcements or custom items

### Welcoming TC to the lang team

https://github.com/rust-lang/team/pull/1488

Josh: Congratulations to TC!

Hear hear! (I was just going to write that) --nikomatsakis

(Many seconds all around.)

### Guest attendee items

TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular.

### Moving right along

TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit. If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause.

### Design meeting at 12:30 EST / 09:30 PST / 17:30 CET

TC: Remember that we have a design/planning meeting that starts half an hour after this call ends.

### Next meeting with RfL

We're next meeting with RfL on 2024-07-03 to review the status of RfL project goals.

https://github.com/rust-lang/rfcs/pull/3614

## Rust 2024 review

Project board: https://github.com/orgs/rust-lang/projects/43/views/5

None.

### Meta

TC: We have tracking issues for the Rust 2024 aspects of every item queued for the edition:

https://github.com/rust-lang/rust/issues?q=label%3AA-edition-2024+label%3AC-tracking-issue

For each item, we've identified an *owner*. Our most recent update for item owners is here:

https://rust-lang.zulipchat.com/#narrow/stream/268952-edition/topic/Owners.20update.202024-04-30

Our motivating priorities are:

- Make this edition a success.
- Do so without requiring heroics from anyone.
- ...or stressing anyone or everyone out.

The current timeline to be communicated is:

| Date | Version | Edition stage |
|------------|---------------|--------------------------------|
| 2024-06-13 | Release v1.79 | Checking off items... |
| 2024-07-25 | Release v1.80 | Checking off items... |
| 2024-09-05 | Release v1.81 | Checking off items... |
| 2024-10-11 | Branch v1.83 | Go / no go on all items |
| 2024-10-17 | Release v1.82 | Rust 2024 nightly beta |
| 2024-11-22 | Branch v1.84 | Prepare to stabilize... |
| 2024-11-28 | Release v1.83 | Stabilize Rust 2024 on master |
| 2025-01-03 | Branch v1.85 | Cut Rust 2024 to beta |
| 2025-01-09 | Release v1.84 | Announce Rust 2024 is pending! |
| 2025-02-20 | Release v1.85 | Release Rust 2024 |

### Tracking Issue for Lifetime Capture Rules 2024 (RFC 3498) #117587

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

TC: With the acceptance of RFC 3617, the adoption of `+ use<..>` syntax, and the great work by CE, this is looking to be in good shape for the edition.

### Reserve gen keyword in 2024 edition for Iterator generators #3513

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

TC: With the acceptance of RFC 3513 and the great work by Oli, this is looking to be in good shape for the edition.

### Tracking issue for promoting `!` to a type (RFC 1216) #35121

**Link:** https://github.com/rust-lang/rust/issues/35121
**Link:** https://github.com/rust-lang/rust/pull/123508

TC: This item is now ready for Rust 2024.

## Nominated RFCs, PRs, and issues

### "Decide on Rule 4 variant for match ergonomics" rust#127257

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

TC: In our 2024-06-26 design meeting on match ergonomics (part 3):

- https://github.com/rust-lang/lang-team/issues/268

...we decided on a slate on rules:

- **Rule 1**: When the DBM is not `move` (whether or not behind a reference), writing `mut` on a binding is an error.
- **Rule 2**: When a reference pattern matches against a reference, do not update the DBM.
- **Rule 3**: If we've previously matched against a shared reference in the scrutinee (or against a `ref` DBM under *Rule 4*, or against a mutable reference treated as a shared one or a `ref mut` DBM treated as a `ref` one under *Rule 5*), set the DBM to `ref` whenever we would otherwise set it to `ref mut`.
- **Rule 4**: If an `&` or `&mut` pattern is being matched against a non-reference type **and if** the DBM is `ref` or `ref mut`, match the pattern against the DBM as though it were a type.
- **Rule 5**: If an `&` pattern is being matched against a mutable reference type (or against a `ref mut` DBM under *Rule 4*), act as if the type were a shared reference instead (or that the `ref mut` DBM is a `ref` DBM instead).

In discussion toward the end of and after the meeting, there emerged some potentially good reasons to adopt a slight variation of *Rule 4*. The motivation is that, under *Rule 4*, this is an error:

let [&mut x] = &mut [&T]; //~ ERROR

(`T` here is a unit struct that implements `Copy`.)

That's kind of awkward and unfortunate, because without the `&mut` in the pattern, we get a type of `&mut &T`, so we really want adding `&mut` to get us a `&T`, since, in all other cases, that's what happens.

We can make this work with a small *tweak* to *Rule 4* (which we'll call the *extended Rule 4*):

- **Rule 4 (extended)**: If an `&` pattern is being matched against a non-reference type *or an `&mut` pattern is being matched against a shared reference type* or a non-reference type, **and if** the DBM is `ref` or `ref mut`, match the pattern against the DBM as though it were a type.

(*Emphasis* highlights the diff.)

We've analyzed this now, and think it's OK and a good tweak. We nominate to confirm this sounds good to the team.

If adopted, we'll revise *Rule 4* to be the extended version.

TC: Are we OK with this amendment to our consensus?

NM: +1 to the revised rule. Does this cover the design goals that Nadri had?

TC: Yes, it covers that.

tmandry: +1 on the revised rule. I'm pleasantly surprised the extended rule is so clean.

Josh: +1, this rule sounds completely sensible to me.

### "Rescope temp lifetime in let-chain into IfElse" rust#107251

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

TC: This PR is about shortening, over an edition, the scope of temporary lifetimes in if-let scrutinees so that they end before the `else` block. The current rules are a particular problem for let-chains which we hope to stabilize.

Ding assembled this report based on our request:

https://hackmd.io/@dingxf/rkJXW-0BA

TC: What do we think?

NM: We didn't bottom this one out yet. Ding did post a new draft.

### "Async closures" rfcs#3668

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

TC: CE proposes for us async closures. These form part a key part of the roadmap proposed in the async project goal, as these enable library innovation in the async Rust ecosystem.

These solve two main problems. One is that we cannot currently express higher-ranked bounds on async function signatures, so this doesn't work:

async fn callee<F, Fut>(_: F)
where
    F: for<'a> FnMut(&'a ()) -> Fut,
    Fut: Future<Output = ()>,
{
}

async fn caller() {
    async fn nop(_: &()) {}
    callee(nop).await;
    //~^ ERROR mismatched types
    //~| NOTE one type is more general than the other
}

The other is that closures cannot return futures that borrow from their captures, so this fails:

use core::future::ready;

async fn callee<F, Fut>(_: F)
where
    F: for<'a> FnMut(&'a ()) -> Fut,
    Fut: Future<Output = ()>,
{
}

async fn caller() {
    let mut xs = vec![];
    callee(|x| async {
        xs.push(*ready(x).await);
    })
    .await;
    //~^ ERROR lifetime may not live long enough
    //~| NOTE captured variable cannot escape `FnMut`
    //~|      closure body
    //~| NOTE async block may outlive the current function,
    //~|      but it borrows `x`, which is owned by the
    //~|      current function
}

The RFC solves this with `async Fn*` trait bounds and with `async || ()` closures, e.g.:

#![feature(async_closure)]

use core::future::ready;

async fn callee<F: async FnMut(&())>(_: F) {}

async fn caller() {
    let mut xs = vec![];
    callee(async |x| {
        xs.push(*ready(x).await);
    })
    .await;
}

There's an extensive explanation for why this is the best way to solve the problem, both in the RFC and in this blog post:

- https://hackmd.io/@compiler-errors/async-closures

The RFC leaves the underlying `AsyncFn*` traits (and all of their associated types) as unnameable to leave us future room to maneuver, e.g. so that we can later work these into a more general `LendingFn*` hierarchy.

Aside from reviewing this generally, there's one item that deserves our attention, which is whether the associated types on the underlying `AsyncFn*` traits should have `Future` or `IntoFuture` bounds. In either case, concrete `async |..| { .. }` closures would return opaque types that implement `Future`, but this would affect what `F: async FnMut()`-style bounds mean, and it would constrain the details of these traits that we may later choose to stabilize.

The question probably comes down to whether we're *betting* on `IntoFuture`. That is, whether we think that bounds should generally require `IntoFuture` (and `IntoIterator`, `IntoAsyncGen`, etc.) rather than requiring `Future` (and `Iterator`, `AsyncGen`, etc.).

There's some sense in requiring the weaker bounds. It's generally better to ask of callers the minimum that we require, and it's hard to think of cases where the `Into*` bounds aren't enough.

There's a practical angle here, in that `IntoFuture` for a type can be implemented using an `async` block and ATPIT, e.g.:

struct AlwaysAsync42;
impl IntoFuture for AlwaysAsync42 {
    type Output = impl Iterator<Item = impl Fn() -> u8>;
    type IntoFuture = impl Future<Output = Self::Output>;
    fn into_future(self) -> Self::IntoFuture { async {
        core::iter::repeat(|| 42)
    }}
}

...whereas implementing `Future` for a type requires implementing `poll` directly. This will also be true of `AsyncGen` (that `IntoAsyncGen` can be implemented with `async gen { .. }` blocks) and of `Iterator` (that `IntoIterator` can be implemented with `gen { .. }` blocks).

Of course, this affordance is most useful if the `Into*` variants can be used in most places. Arguably, this is a kind of direction that we've signaled by allowing types that implement `IntoIterator` to be used directly in `for` loops and types that implement `IntoFuture` to be used directly with `.await`.

What these `async Fn*` bounds mean will likewise be a signal to and influence the ecosystem. If they mean the tighter bound, those tighter bounds will of course proliferate because of the convenience and increased expressiveness of this syntax.

There are two main downsides to using the `IntoFuture` bound here on the associated types. One is that many existing functions in the ecosystem take `Future` rather than `IntoFuture` in their bounds. In generic code, one would then need to write, e.g.:

async fn my_fun(f: impl async Fn()) {
    takes_future(f.into_future()).await;
}

The deeper problem is what this would mean for the way that the async closures RFC extends RTN. This RFC allows for, e.g., this solution to the `Send` bound problem:

fn spawn<F: IntoFuture<IntoFuture: Send>>(f: F) {
    todo!()
}

async fn callee<F: async FnMut(), F(..): Send>(f: F) {
    //                            ^^^^^^^^^^^
    //                            ^ Extension to RTN.
    spawn(f);
}

So then, if we say that `f`, when called, returns a type that implements `IntoFuture`, we have to ask whether the `F(..): Send` syntax should constrain the `IntoFuture` type or whether it should "look through" it and constrain the `Future` returned by calling `into_future` (or maybe both).

There doesn't seem to be a conservative option that leaves us room here. We just need to make the right choice and the one that we'll hopefully regret the least.

TC: What do we think?

CE: If we went with `IntoFuture`, I'd want the RTN syntax to bound the `IntoFuture`, and if you wanted to bound the `Future`, you'd write something like this:

where F: async Fn(),
F(..)::Future: Send,

CE: I don't want RTN to do anything magic/sneaky.

CE: I'm kind of on the fence in general of whether using `IntoFuture` is worth it.

NM: I feel pretty strongly that `IntoFuture` would be the wrong decision. I want an equivalence:

async Fn() == version of the Fn trait that has an `async fn call`

NM: I think this is why we're seeing the ergnomic salt here. At the same time, I do want people to bound on `IntoFuture`. The way I see it is that `IntoFuture` (like `IntoIterator`) means "something that is not a future but has a natural correspondence to one". We've already committed that `async fn` returns an *actual future* and not "something that can be made into a future" in other contexts. Typically one should take an `impl IntoFuture` as an argument nonetheless.

CE: I agree with Niko.

Josh: I agree with what Niko is saying and that we should go with `Future` and not `IntoFuture`. I think `IntoFuture` is great and we should support it in more places, but I think an `async fn` should continue to be one that returns a *`Future`*, not an `IntoFuture`.

scottmcm: My instinct following the `Iterator` thing is to accept `IntoFuture` and return `Future`.

eholk: Want to highlight Niko's point about how `async fn` is a closure that returns futures which is analogous an `IntoFuture` that turns into a `Future`.

eholk: I've been playing with an alternate formulation of `Future` around a `Move` trait instead of `Pin`, and the `IntoFuture/Future` split is really helpful there so separate the unpinned and pinned portion of a `Future`'s lifetime. But this would require a `Future 2.0` trait and needs its own migration story, so it doesn't really make sense to try to be future compatible now because it's just not possible.

tmandry: Like Eric said, there'd have to be a big transition anyway if we were to do the thing being discussed in Zulip. One thing that I find interesting about this idea is that we might need a similar trick for generators. They need to be pinned to implement `Future`. So there might be a parallel there that I'd like to explore a bit. I'd bet we'll still go with the current design for async closures. But it's worth looking into that.

TC: Sounds good. I'll resolve the concern then.

### "Reorder trait bound modifiers *after* `for<...>` binder in trait bounds" rust#127054

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

TC: CE proposes for us:

> This PR suggests changing the grammar of trait bounds from:
>

[CONSTNESS] [ASYNCNESS] [?] [BINDER] [TRAIT_PATH]

const async ? for<'a> Sized

>
> to
>

[BINDER] [CONSTNESS] [ASYNCNESS] [?] [TRAIT_PATH]

for<'a> const async ?Sized

>
> ### Why?
> I think it's strange that the binder applies "more tightly" than the `?` trait polarity. This becomes even weirder when considering that we (or at least, I) want to have `async` trait bounds expressed like:
>

where T: for<'a> async Fn(&'a ()) -> i32,

>
> and not:
>

where T: async for<'a> Fn(&'a ()) -> i32,

>
> ### Fallout
>
> No crates on crater use this syntax, presumably because it's literally useless. This will require modifying the reference grammar, though.

TC: What do we think?

Josh: Huge +1 for moving it before `?`. To be clear, `const` and `async` aren't in anything stable?

CE: Correct.

Josh: It seems maybe open whether we'd want to allow, e.g. `const` and `async` in any order, but that's a question we can defer. It's not clear what the generalized versions of these mean, and that meaning could affect what we want to allow here.

tmandry: There is some conceptual appeal to the current arrangement, but it doesn't seem that it will ever matter, and people would probably think it doesn't make sense, so I'm OK with doing this.

scottmcm: Let's do this.

CE: To confirm, everyone agrees that `for<'a> async Fn()` is the correct order?

tmandry, Josh, TC, scottmcm: Yes.

Josh: Conditional on us deciding that we want the `async Fn` or similar syntax rather than `AsyncFn`, it definitely makes more sense to have the `for<'a>` come *before* the `async`.

scottmcm: It's `unsafe async fn`, right? Not `async unsafe fn`?

tmandry: Trying it on the playground, it's `async unsafe fn`.

CE: Maybe we need to fix that too.

scottmcm: I do like that we have a fixed order...

Josh: I'm sad about the order though. +1 that it should have been `unsafe async fn`.

CE: There's also `const async unsafe fn`. But `const async` doesn't exist (but that's not enforced at the parser level).

Josh: Is there appetite to fix this?

CE: We can fix `const`.

scottmcm: There is some reason, the `unsafe fn` is a tighter atomic, because `unsafe fn(i32) -> i32` exists in a way that `const fn` pointers don't.

TC: Going back to the main question, it sounds like our consensus here is to just break this to make it what we want, given the lack of fallout. I've proposed FCP merge on that.

### "Tracking issue for RFC 2523, `#[cfg(version(..))]`" rust#64796

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

TC: Wesley Wiser, the compiler team lead, nominates this for us:

> This was marked as blocked on #64797 two years ago but #64797 still has open design questions and does not appear ready for stabilization anytime soon whereas this feature has no open design questions and is fully implemented. Since #64797 does not address some important use cases such as conditionally using compiler or language features and use of [`version_check`](https://crates.io/crates/version_check/) continues to grow (now at >229M all-time downloads and upward-trending daily downloads), I think it makes sense to revisit stabilization of this feature.

The issue we had marked it blocked on is RFC 2523, `#[cfg(accessible(::path::to::thing))]`.

- https://github.com/rust-lang/rust/issues/64797
- https://github.com/rust-lang/rfcs/pull/2523

This was last proposed for stabilization 2021-03-16:

- https://github.com/rust-lang/rust/issues/64796#issuecomment-799847092

Josh said at that time:

> Based on that report, this feature seems ready in isolation.
>
> However, when last we discussed this feature, we also had the concern that stabilizing a compiler `version` check before stabilizing `accessible` would have a negative effect on the ecosystem, by pushing people towards version checks rather than feature checks. I feel that that concern still holds.
>
> I'm furthermore concerned that once we _have_ `version`, there will be even less motivation to work on `accessible`.

cramertj proposed it for FCP merge anyway:

> @joshtriplett I agree that it would be better if we could stabilize `accessible` first. However, I do think this is a very useful feature, and there is real harm done to the ecosystem by not providing it. I also believe that, once `accessible` is made available, we will be able to successfully encourage the ecosystem best practices to adapt (over time). `accessible` is currently at the pre-implementation phase, whereas this feature has been implemented and had time to bake on nightly for months. With that in mind, I personally would be in favor of moving forwards with stabilization.

Niko was +1:

> I look forward to having this feature available. It may also help with some questions around the async libraries, as it enables one to have methods that move to libstd and "disappear" from the futures crate at the same time.
>
>
> I agree that it would be nice to make progress on accessible as well-- my impression when last we spoke was that accessible is largely implemented? I may be misremembering.
>
> However, in general, I don't like holding up things that are ready because of other things that are not yet ready.

Josh then registered a concern:

> I'm going to go ahead and register this as a concern, precisely _because_ `accessible` is harder than `version`. Other ecosystems (e.g. C) had version-detection much earlier than they had feature-detection, and the effects of that are quite visible in the ecosystem. I'm quite concerned that `version` will become the "good enough" mechanism for detection, and `accessible` won't end up happening.
>
> @est31 To be clear, I do think we need both, precisely because `accessible` only works for library changes, not for language changes. I'd love to have a variant of `accessible` that works for language changes as well, but there are multiple ways we could do that.
>
> Note: this concern is predicated on the understanding that `accessible` is feasible to implement, and "just" needs further implementation work. If that turns out to not be the case, and there's some critical blocking issue that prevents implementing `accessible` as specified, then I'd like to see it re-specified in a fashion that'd be more feasible to implement, but I'd be willing to drop this concern because I don't think stabilizing `version` should wait on further _design_ work.

Niko later canceled FCP. Josh later commented:

> It looks like `cfg(accessible(...))` may be at a state where we could stabilize enough of it to be generally useful, and what's available is enough that I'd consider it to unblock this.

TC: Where are we on this?

Josh: That's a correct history. I'd love to see this feature, and I think the Cargo team would like to see it too. I continue to stand by the premise that the web and C have demonstrated what happens if you have version detection before feature detection, and that becomes a worse ecosystem. There's also how this affects alternate implementations.

Josh: The fully general version of `cfg(accessible(..))` probably won't be shippable anytime soon. There are some weird cycles there between cfg(accessible) and writing/importing modules and . Petrochenkov has notes on this. The version that's currently implemented, though, would be enough to detect things in `core` and `std`. If we shipped that version alone, that would be enough for me to resolve this concern. We could then extend that in the future.

tmandry: If we had `cfg(accessible(..))`, there are still reasons that we'd have `cfg(version(..))`...

Josh: Yes, agreed.

tmandry: Have we talked about feature detection on feature names, and would that subsume some of this?

Josh: We do have feature names for new things we introduce. I'd be OK with that.

tmandry: Does that subsume all of `cfg(version(..))`?

Josh: No. Bugs still come into play, and there's no name for "rustc fixed this bug".

scottmcm: On the feature name thing, it's another name that we have to pick for *forever*. So it'd be something else we need to gate and review. So I'd like to avoid that if at all possible. I wouldn't want to have to do a pass over all the old names. (For example, we have feature names like `const_alloc_layout_size_align` and `alloc_layout_manipulation` that aren't necessarily great, but are today totally fine because they don't matter in stable, and on nightly bad names are fine and changable.)

TC: +1.

(The first part of the triage meeting ended here. We'll be back for part 2.)

---

(The second part of the triage meeting started here.)

Josh: I'd be open to other options if we first explored the possibility of stabilizing the minimal version of `cfg(accessible(..))` and find that the minimal version (only supporting std/alloc/core) isn't viable.

TC: It sounds like we should ask about that.

tmandry: There are issues with paths in attributes. Not sure whether limiting this to `core` and `std` would make this better. But we can ask about that.

TC: I'll reply to this effect on the issue.

### "[type-layout] Document minimum size and alignment" reference#1482

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

TC: This documents some properties proposed by RalfJ:

> * Every type, including unsized types, has a _minimal_ size and a _minimal_ alignment
> * For sized types, the minimal size and alignment match their regular size and alignment
> * For slices, the minimal size is 0 and the minimal alignment is the alignment of the element type
> * For `dyn Trait`, the minimal size is 0 and the minimal alignment is 1
> * For struct types with an unsized field, the minimal size and alignment is computed using the minimal size and alignment of that field
> * The minimal size of all types is less than `isize::MAX`

TC: scottmcm nominates this for us. What do we think?

TC: Note that the PR seems to have been updated since the text above, so let's look at the PR.

NM: I'll leave a comment with a question; otherwise looks fine.

(TC: RalfJ later commented that there are problems with this language, and that https://github.com/rust-lang/rust/pull/126152 covers what is needed here for the moment, so we closed in favor of that.)

### "elaborate on slice wide pointer metadata" reference#1499

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

TC: RalfJ proposes to update some language in the Reference to say this, after the changes:

> * A reference or `Box<T>` that is [dangling], misaligned, or points to an invalid value (using the actual dynamic type of the pointee in case of dynamically sized types).
> * Invalid metadata in a wide reference, `Box<T>`, or raw pointer. The requirement for the metadata is determined by the type of the unsized tail:
> * `dyn Trait` metadata is invalid if it is not a pointer to a vtable for `Trait`.
> * Slice metadata is invalid if the length is not a valid `usize` (i.e., it must not be read from uninitialized memory). Furthermore, for wide references and `Box<T>`, slice metadata is invalid if it makes the total size of the pointed-to value bigger than `isize::MAX`.

TC: What do we think?

See:

https://github.com/rust-lang/reference/pull/1499/files

Josh: According to Ralf, this is mostly clarification of language, and to the extent that it's a semantic change, it's consistent with the previous item: it's invalid to have slice metadata that would make the total size bigger than `isize::MAX` bytes.

NM: This seems pretty reasonable. Looks good to me.

Josh: +1, ship it.

TC: +1.

scottmcm: I'll start an FCP here. This implies also acceptance of:

https://github.com/rust-lang/rust/pull/121965

...which we discuss later below.

(TC: This is now in FCP.)

### "more explicitly explain the UB around immutable extern statics" reference#1502

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

TC: RalfJ suggests to add to the Reference:

> The bytes owned by an immutable binding *or immutable `static`* are immutable, unless those bytes are part of an [`UnsafeCell<U>`].

(Emphasis added.)

And:

> Once Rust code runs, mutating an immutable static (from inside or outside Rust) is UB, except if the mutation happens inside an `UnsafeCell`.

TC: What do we think?

TC: This looks right to me.

NM: This looks right, +1. Maybe I'll ask for a clarification on a piece here.

Josh: The only concern I'd have is that we do have mutable statics but recommend against them... I wonder if any people are currently abusing immutable statics and whether this would surprise people. We'd want to tell people clearly what to do instead.

tmandry: The answer would probably be to use `UnsafeCell`.

NM: clarification that you can't literally use `UnsafeCell` because the type is not `Sync`, it needs to be "newtyped":

static S: UnsafeCell<Foo> = ...; // not sync, error
static S: SyncUnsafeCell<Foo> = ...; // equivalent but sync

NM: posted a clarification

TC: We'll get the answer to that clarification, then merge this on the rustdocs side.

(TC: RalfJ answered, we included the clarification in the text, and have now merged it.)

### "RFC: Implementable trait aliases" rfcs#3437

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

TC: We discussed this in the lang planning meeting in June, and it looks like there have been updates since we last looked at this, so it's time for us to have another look since we seemed interested in this happening.

TC: What do we think?

NM: Tyler and I had talked about this last week. This is an important part of the async story.

trait Service = LocalService<invoke(..): Send> + Send

trait LocalService {
    async fn invoke();
}

In my opinion the RFC should basically just say that there is an equivalence, the rest is impl deatil:

trait Alias<..> = Bound + Bound1... where WC;

// ...should be equivalent to...

trait Alias<..>: Bound + Bound1... where WC { }

impl<T: Bound + Bound1..., ..> Alias<..> for T
where WC {}

NM: Already today, if you don't have WCs, these are equivalent. We have to decide how we want WCs to behave, I think they should become implied bounds. We should say that these should be equivalent. We can stabilize the subset that is equivalent today, then we can consider other cases.

TM: Note that the RFC today doesn't support `+ Send` but it should. Limiting to auto traits seems ok.

JT: Did we accept an RFC for implementing a trait "via" a subtrait? (answer: no) Seems like a natural pairing. Both let people adjust their trait structure while providing backwards compatibility.

NM: I wanted to add that in the absence of that RFC implementing an alias has a complex semantics of "implementing the bounds" and not the trait itself. I would like that RFC as well.

NM: Also be aware of the back-compat hazard (can be fixed) if one base trait adds a method creating a conflict.

scottmcm: I would say we should lump the two together into one RFC and identifying that the purpose is to allow splitting traits and other similar transformations.

NM: I like the idea of the RFC having the shape of "transformations that are equivalent", e.g., splitting out supertraits.

tmandry: Are you viewing the list of bounds in a trait alias as supertraits of the trait alias?

scottmcm: not sure, haven't thought that hard about it.

Josh: Also not sure but that sounds approximately right.

Niko: I've thought about it extensively and I *am* sure.

Josh (and others): Well, I'm glad someone is! (cue laugh track).

NM: Supertraits are the "forward" direction of the implication (`T: Alias` implies `T: Bound`) and the blanket impl goes in the "reverse" (`T: Bound` implies `T: Alias`). So an alias has an "if and only if" relationship, and hence they are equivalent. I'm ignoring where-clauses for the purposes of this discussion, they behave differently today (they lack the first implication) but I see that as a bug.

NM: I'll give guidance to Jules about this on the issue.

### "`repr(discriminant = ...)` for type aliases" rfcs#3659

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

TC: This RFC proposes to allow:

type Byte = u8;
#[repr(discriminant = Byte)]
enum E {
    One,
    Two,
}

It requires the `discriminant = ` so that we don't step on the space of valid representations.

TC: Josh proposed FCP merge and nominated. What do we think?

(Discussion to the effect that we're in favor of this. This is now in FCP.)

### "Fix ambiguous cases of multiple & in elided self lifetimes" rust#117967

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

TC: adetaylor proposes to adjust some rules for how elided lifetimes work. This was originally proposed for T-types FCP, but then they decided this was probably a lang matter after all.

TC: What do we think?

Now rejected:

fn a(self: &Box<&Self>) -> &u32
fn b(self: &Pin<&mut Self>) -> &String
fn c(self: &mut &Self) -> Option<&Self>
fn d(self: &mut &Box<Self>, arg: &usize) -> &usize // previously used the lt from arg

Old behavior:

fn a<'a>(self: &Box<&'a Self>) -> &'a u32
fn b<'a>(self: &Pin<&'a mut Self>) -> &'a String
fn c<'a>(self: &mut &'a Self) -> Option<&'a Self>
fn d(self: &mut &Box<Self>, arg: &usize) -> &usize // previously used the lt from arg

Change in behavior:

fn e(self: &mut Box<Self>, arg: &usize) -> &usize;
// Was interpreted as borrowing from `arg`, now interpreted as borrowing from `self`.

NM: I'm not worried about this. It could go the other way too, that you could have unsound code today that this change would make sound, because people might have already expected this behavior.

Josh: Would love to see us deprecate multi-argument lifetime elision one day, once we have lifetimes like `'self` and `'arg` that you don't have to explicitly define.

NM: I have thought about, if we had that, perhaps simply disallowing lifetime elision in return type position.

Josh: I'm not sure I'd go that far.

NM: I'll propose FCP merge on this issue.

scottmcm: I'd love to see a large elision rethink now that we have so much more experience with it.

### "offset_from: always allow pointers to point to the same address" rust#124921

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

TC: Over in:

- https://github.com/rust-lang/rust/pull/117329 ("offset: allow zero-byte offset on arbitrary pointers)

...we asked RalfJ to split off the proposal for `offset_from`. He did that, and this nomination is that proposal.

TC: What do we think?

scottmcm: Another recent conversation about it <https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/ptrsub.20vs.20provenance.20monotonicity/near/443439654>

Josh: Yes, this seems fine.

(TC: Josh proposed FCP, and this is now in FCP.)

### "Tracking issue for function attribute `#[coverage]`" rust#84605

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

TC: This is about stabilizing a `#[coverage(off)]` attribute to exclude items from `-Z instrument-coverage`.

Josh proposed FCP merge and nominated this for us.

> Let's go ahead and see if we have consensus to stabilize this _other_ than the potential issue of applying it automatically to nested functions or inlined functions.
>
> My proposal would be that `coverage(off)` should automatically apply to functions (and closures) nested inside the function in question, but that it _shouldn't_ automatically apply to inlined functions.
>
> Rationale: putting `#[coverage(off)]` on a function should apply to everything inside it for convenience, but things it _calls_ might still want coverage for other reasons. I'd propose that if we want something that recursively disables coverage, that should be an additional attribute.
>
> However, this is a loosely held position, and I'd love to see a good argument / use case for also disabling it on inlined functions.

Correspondingly, there are two open questions about applying this automatically to nested functions and to inlined functions.

Checkboxes are here:

https://github.com/rust-lang/rust/issues/84605#issuecomment-1937373497

TC: What do we think?

TC: This is in FCP, so we'll unnominate.

### "Elaborate on the invariants for references-to-slices" rust#121965

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

TC: scottmcm filed this issue and explains:

> The length limit on slices is clearly a safety invariant, and I'd like it to also be a validity invariant. With [function parameter metadata](https://discourse.llvm.org/t/rfc-metadata-attachments-for-function-arguments/76420?u=scottmcm) making progress in LLVM, I'd really like to be able to use it when `&[_]` is passed as a scalar pair, in particular.
>
> The documentation for references is cagey about what exactly is a validity invariant, so for now just elaborate on the consequences of the existing safety rules on slices -- the length restriction follows from the `size_of_val` restriction -- as a way to help discourage people from trying to violate them.
>
> I also made the existing warning stronger, since I'm fairly sure it's already UB to violate at least the "references must be non-null" rule, rather than it just being that it "might be UB in the future".

Then joboet nominated this for us with:

> Given that `slice::from_raw_parts` already states that "the total size `len * mem::size_of::<T>()` of the slice must be no larger than `isize::MAX`" and that its behaviour is undefined otherwise, I'd say that this is entirely uncontroversial. Still, I'd appreciate some team sign-off on this, I think this concerns lang?

RalfJ thinks this should probably be a dual T-lang / T-opsem FCP.

TC: What do we think?

scottmcm: (Discussion on background here.)

Josh: This seems consistent with the earlier change to the Reference that we approved.

https://github.com/rust-lang/rust/pull/121965

(TC: We agreed to FCP the Reference change, and that the Reference change implies acceptance of the change in this PR.)

### "`#![crate_name = EXPR]` semantically allows `EXPR` to be a macro call but otherwise mostly ignores it" rust#122001

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

TC: In previous stable versions of Rust, `#![crate_name = EXPR]` worked. That is, within `EXPR` we expanded and then used macro calls such as `concat`.

However, due to:

https://github.com/rust-lang/rust/pull/117584

...we broke this, and then we shipped it in stable Rust v1.77.

Except, we only half broke it. It doesn't work, but neither is it a hard error. It just quietly ignores the result.

We discussed this in the meeting on 2024-03-27 and agreed this was the worst of all worlds, and so we should at a minimum break it completely, and then we could always later decide to relax the hard error and make it work again by reverting #117584. On that basis, scottmcm proposed FCP merge.

TC: What do we think?

tmandry: This finished FCP, we can unnominate.

### "Assert that the first `assert!` expression is `bool`" rust#122661

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

TC: estebank describes this issue for us:

> In the desugaring of `assert!` in 2024 edition, assign the condition expression to a `bool` biding in order to provide better type errors when passed the wrong thing.
>
> The span will point only at the expression, and not the whole `assert!` invocation.
>

error[E0308]: mismatched types
  --> $DIR/issue-14091.rs:2:13
   |
LL |     assert!(1,1);
   |             ^ expected `bool`, found integer

>
> We no longer mention the expression needing to implement the `Not` trait.
>

error[E0308]: mismatched types
  --> $DIR/issue-14091-2.rs:15:13
   |
LL |     assert!(x, x);
   |             ^ expected `bool`, found `BytePos`

>
> In <=2021 edition, we still accept any type that implements `Not<Output = bool>`.

TC: And pnkfelix nominates this for us:

> At the very least, we might need to tie such a change to an edition.
>
> I am not certain whether this decision would be a T-lang matter or a T-libs-api one. I'll nominate for T-lang for now.
>
> (Namely: The question is whether we can start enforcing a rule that the first expression to `assert!` must be of bool type, which is how the [macro is documented](https://doc.rust-lang.org/std/macro.assert.html), but its current behavior is a little bit more general, as demonstrated in my [prior comment](https://github.com/rust-lang/rust/pull/122661#issuecomment-2004197554))
>
> ...
>
> There _is_ a design space here. E.g. one set of options is:
>
> 1. (stable Rust behavior): in all editions, support arbitrary `impl Not<Output=bool>` for first parameter to `assert!`;
> 2. in edition >= 2024, support _just_ `Deref<Target=bool>` for first parameter to `assert!` (e.g. by expanding to `let x: &bool = &$expr;`), or
> 3. (this PR): in edition >= 2024, support _just_ `bool` for first parameter to `assert!`.
>
> (And then there's variations thereof about how to handle editions < 2024, but that's a separate debate IMO.)

TC: What do we think?

(We discussed and felt this was libs-api. Josh will leave a comment to that effect inviting also pnkfelix to reply if he wants to defend the lang nomination.)

### "Raw Keywords" rfcs#3098

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

TC: We've at various times discussed that we had earlier decided that if we wanted to use a new keyword within an edition, we would write it as `k#keyword`, and for that reason, we prefer to not speculatively reserve keywords ahead of an edition (except, perhaps, when it's clear we plan to use it in the near future).

TC: Somewhat amusingly, however, we never in fact accepted that RFC. Back in 2021, we accepted scottmcm's proposal to **cancel**:

> We discussed this RFC again in the lang team triage meeting today.
>
> For the short-term goal of the reservation for the edition, we'll be moving forward on #3101 instead. As such, we wanted to leave more time for conversations about this one, and maybe use crater results from 3101 to make design changes,
>
> @rfcbot cancel

Instead we accepted RFC 3101 that reserved `ident#foo`, `ident"foo"`, `ident'f'`, and `ident#123` starting in the 2023 edition.

Reading through the history, here's what I see:

- What do we want to do about Rust 2015 and Rust 2018? It's a breaking change to add this there. Is this OK? Do we want to do a crater run on this?
- Would we have the stomach to actually do this? It's one thing to *say* that if we wanted to use a new keyword within an edition, we'd write `k#keyword`, but it's another to actually do it in the face of certain criticism about that being e.g. unergonomic. Would we follow through?

TC: What do we think?

All: "Didn't we do this already? No? Oh, right, that's the point."

(The meeting ended here.)

---

### "Stabilize `extended_varargs_abi_support`" rust#116161

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

TC: This stabilization was nominated for us, with pnkfelix commenting:

> Just to add on to @cjgillot 's comment above: @wesleywiser and I could not remember earlier today whether T-lang _wants_ to own FCP'ing changes like this that are restricted to extending the set of calling-conventions (i.e. the `conv` in `extern "conv" fn foo(...)`), which is largely a detail about what platforms one is interoperating with, and not about changing the expressiveness of the Rust language as a whole in the abstract.
>
> (My own gut reaction is that T-compiler is a more natural owner for this than T-lang, but I wasn't certain and so it seems best to let the nomination stand and let the two teams duke it out.)

TC: What do we think about 1) this stabilization, and 2) whether we want to own this?

NM: I think compiler or others are better positioned to decide this. (I don't want this to be FCP'd.)

### "Don't make statement nonterminals match pattern nonterminals" rust#120221

compiler-errors NOTE: **this is in FCP, don't need to discuss it anymore**

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

TC: CE handed this one to us, since it changes the contract of macro matchers.

Here's the code that does not work today that we would make work:

macro_rules! m {
    ($pat:pat) => {};
    ($stmt:stmt) => {};
}

macro_rules! m2 {
    ($stmt:stmt) => {
        m! { $stmt }
        //~^ ERROR expected pattern
    };
}

m2! { let x = 1 }

This code does not work because we consider `:stmt` to be a possible `:pat` even though we then always reject it later in the process. By saying that `:stmt` cannot be a `:pat`, we make this code work.

We discussed this in the meeting on 2024-03-27:

> CE: Right now the tokens that a macro matcher may begin with is a stable guarantee. We are relaxing the assumption that pattern matchers may begin with statement metavariables ($var whose type is stmt), because when we actually try to *parse* such a pattern, we are always guaranteed to fail. This only allows more code to compile, and would only break future code if we specifically wanted to begin patterns with *statement metavariable*.
>
> scottmcm: I agree that it's weird to allow a `:stmt` in a pattern, so am happy to say we won't. Let's see what others think, since this conversation was in a sparsely-attended triage meeting:
>
> scottmcm: The other thing we explored was what it would take to make this actually work, since you can actually put an `:expr` into a pattern. But CE argued that we don't actually like that that works, it's just something we're stuck with because people used it before `:literal` was available, which seems fair.

TC: What do we think?

### "Initial support for auto traits with default bounds" rust#120706

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

TC: This is related to this MCP about a path toward async drop and scoped tasks:

https://github.com/rust-lang/compiler-team/issues/727

TC: petrochenkov gives some background:

> So, what are the goals here:
>
> * We want to have a possibility to add new auto traits that are added to _all_ bound lists by default on the current edition. The examples of such traits could be `Leak`, `Move`, `SyncDrop` or something else, it doesn't matter much right now. The desired behavior is similar to the current `Sized` trait. Such behavior is required for introducing `!Leak` or `!SyncDrop` types in a backward compatible way. (Both `Leak` and `SyncDrop` are likely necessary for properly supporting libraries for scoped async tasks and structured concurrency.)
> * It's not clear whether it can be done backward compatibly and without significant perf regressions, but that's exactly what we want to find out. Right now we encounter some cycle errors and exponential blow ups in the trait solver, but there's a chance that they are fixable with the new solver.
> * Then we want to land the change into rustc under an option, so it becomes available in bootstrap compiler. Then we'll be able to do standard library experiments with the aforementioned traits without adding hundreds of `#[cfg(not(bootstrap))]`s.
> * Based on the experiments, we can come up with some scheme for the next edition, in which such bounds are added more conservatively.
> * Relevant blog posts - https://without.boats/blog/changing-the-rules-of-rust/, https://without.boats/blog/follow-up-to-changing-the-rules-of-rust/ and https://without.boats/blog/generic-trait-methods-and-new-auto-traits/, https://without.boats/blog/the-scoped-task-trilemma/
> * Larger compiler team MCP including this feature - [MCP: Low level components for async drop compiler-team#727](https://github.com/rust-lang/compiler-team/issues/727), it gives some more context

We discussed this in the async WG on 2024-03-25 and commented:

> This is interesting work, but there's a lot to review here. We'd be particularly interested in seeing something in the way of a design document here, specifically e.g. with respect to when these bounds are added and when they are not, and how they interact with the `?` bounds. Seeing the algorithm spelled out in words and in theory would definitely help us understand this. The best place to put this may be in the [rustc-dev-guide](https://github.com/rust-lang/rustc-dev-guide).

The question here is whether we want to charter this as an experiment.

### "Support ?Trait bounds in supertraits and dyn Trait under a feature gate" rust#121676

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

TC: This is related to this MCP about a path toward async drop and scoped tasks:

https://github.com/rust-lang/compiler-team/issues/727

TC: petrochenkov gives some background:

> Summary:
>
> * [Initial support for auto traits with default bounds #120706](https://github.com/rust-lang/rust/pull/120706) introduces a way to add new auto traits that are appended to all bound lists by default, similarly to existing `Sized`. Such traits may include `Leak`, `SyncDrop` or similar, see [Initial support for auto traits with default bounds #120706 (comment)](https://github.com/rust-lang/rust/pull/120706#issuecomment-1934006762) for more detailed motivation.
> * To opt out from bounds added by default the `?Trait` syntax is used, but such "maybe" bounds are not supported in some contexts like supertrait lists and `dyn Trait + ...` lists, because `Sized` is not added by default in those context.
> * This PR adds a feature for supporting `trait Trait1: ?Trait2`, `dyn Trait1 + ?Trait2` and also multiple maybe bounds in the same list `?Trait1 + ?Trait2`, because the new traits need to be added by default in those contexts too, and `?Sized + ?Leak` may also make sense.
> * We need this to be available in bootstrap compiler, to make experiments on standard library without adding too many `#[cfg(not(bootstrap))]`s
> * Larger compiler team MCP including this feature - [MCP: Low level components for async drop compiler-team#727](https://github.com/rust-lang/compiler-team/issues/727), it gives some more context

TC: The question here is whether we want to charter this as an experiment.

### "Emit a warning if a `match` is too complex" rust#122685

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

TC: Nadri nominates this for us and describes the situation:

> Dear T-lang, this PR adds a warning that cannot be silenced, triggered when a match takes a really long time to analyze (in the order of seconds). This is to help users figure out what's taking so long and fix it.
>
> We _could_ make the limit configurable or the warning `allow`able. I argue that's not necessary because [crater](https://github.com/rust-lang/rust/pull/121979#issuecomment-2003089646) showed zero regressions with the current limit, and it's be pretty easy in general to split up a `match` into smaller `match`es to avoid blowup.
>
> We're still figuring out the exact limit, but does the team approve in principle?

(As an aside, awhile back someone [showed](https://niedzejkob.p4.team/rust-np/) how to [lower](https://github.com/NieDzejkob/rustc-sat) SAT to exhaustiveness checking with `match`. Probably that would hit this limit.)

TC: What do we think?

### "Stabilize `count`, `ignore`, `index`, and `length` (`macro_metavar_expr`)" rust#122808

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

TC: c410-f3r proposes the following for stabilization:

> # Stabilization proposal
>
> This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically, the stabilization of `count`, `ignore`, `index` and `length`.
>
> ## What is stabilized
>
> ### Count
> The number of times a meta variable repeats in total.
>

macro_rules! count_idents {
    ( $( $i:ident ),* ) => {
        ${count($i)}
    };
}

fn main() {
    assert_eq!(count_idents!(a, b, c), 3);
}

>
> ### Ignore
> Binds a meta variable for repetition, but expands to nothing.
>

macro_rules! count {
    ( $( $i:stmt ),* ) => {{
        0 $( + 1 ${ignore($i)} )*
    }};
}

fn main() {
    assert_eq!(count!(if true {} else {}, let _: () = (), || false), 3);
}

>
> ### Index
> The current index of the inner-most repetition.
>

trait Foo {
    fn bar(&self) -> usize;
}

macro_rules! impl_tuple {
    ( $( $name:ident ),* ) => {
        impl<$( $name, )*> Foo for ($( $name, )*)
        where
            $( $name: AsRef<[u8]>, )*
        {
            fn bar(&self) -> usize {
                let mut sum: usize = 0;
                $({
                    const $name: () = ();
                    sum = sum.wrapping_add(self.${index()}.as_ref().len());
                })*
                sum
            }
        }
    };
}

impl_tuple!(A, B, C, D);

fn main() {
}

>
> ### Length
>
> The current index starting from the inner-most repetition.
>

macro_rules! array_3d {
    ( $( $( $number:literal ),* );* ) => {
        [
            $(
                [
                    $( $number + ${length()}, )*
                ],
            )*
        ]
    };
}

fn main() {
    assert_eq!(array_3d!(0, 1; 2, 3; 4, 5), [[2, 3], [4, 5], [6, 7]]);
}

>
> ## Motivation
>
> Meta variable expressions not only facilitate the use of macros but also allow things that can't be done today like in the `$index` example.
>
> An initial effort to stabilize this feature was made in #111908 but ultimately reverted because of possible obstacles related to syntax and expansion.
>
> Nevertheless, [#83527 (comment)](https://github.com/rust-lang/rust/issues/83527#issuecomment-1744822345) tried to address some questions and fortunately the lang team accept #117050 the unblocking suggestions.
>
> Here we are today after ~4 months so everything should be mature enough for wider use.
>
> ## What isn't stabilized
> `$$` is not being stabilized due to unresolved concerns.

TC: I asked WG-macros for feedback on this here:

https://rust-lang.zulipchat.com/#narrow/stream/404510-wg-macros/topic/Partial.20macro_metavar_expr.20stabilization

TC: Josh proposed FCP merge on this stabilization.

### "Supertrait item shadowing v2" rfcs#3624

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

TC: On 2024-04-24, we had discussed (on a gut check basis) a proposal from Amanieu to change method resolution such that when both a subtrait and one of its supertraits are in scope, shadowed methods from the subtrait would be chosen rather than resulting in ambiguity errors.

Most notably, this would allow the standard library to uplift methods from `itertools`, which they've been deferring for years due to no way to do so without causing breakage. But there are many other possible uses and reasons to believe this might be a good rule.

After our last discussion, we had asked for an RFC. This is that RFC. What do we think?

### "Tracking issue for the `start` feature" rust#29633

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

TC: Nils proposes to us that we delete the unstable `#[start]` attribute:

> I think this issue should be closed and `#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
>
> I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
>
> * `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
> * `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things _anyways_
>
> `#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on Windows, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program. So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving _any_ stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
>
> Note that this feature has **not** been RFCed in the first place.

TC: What do we think?

### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378

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

TC: We unnominated this back in October 2023 as more analysis seemed to be needed. Since then, nikomatsakis and tmandry have posted substantive analysis that it seems we should discuss.

### "#[cold] on match arms" rust#120193

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

TC: Apparently our unstable `likely` and `unlikely` intrinsics don't work. There's a proposal to do some work on fixing that and stabilizing a solution here. The nominated question is whether we want to charter this as an experiment.

### "Disallow deriving (other than Copy/Clone) on types with unnamed fields" rust#121270

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

TC: pnkfelix nominates this for us:

> This PR that addresses some ICEs arising for the unstable `feature(unnamed_fields)`, by conservatively mapping the ICE'ing cases to static errors instead.
>
> The T-compiler team wants to know the opinion of T-lang of whether `feature(unnamed_fields)` is sufficiently likely, in the near future, to be removed (or significantly reworked) to such a degree that it would make more sense to close this PR rather than have contributors spend further time on it.
>
> (See also the context established by https://hackmd.io/7r0i-EWyR8yO6po2LnS2rA#Tracking-issue-for-RFC-2102-Unnamed-fields-of-struct-and-union-type-rust49804 (where I think there was supposed to be an eventual writeup of the concerns people had with `feature(unnamed_fields)`) and [#49804 (comment)](https://github.com/rust-lang/rust/issues/49804#issuecomment-2106381721) )

On 2024-05-12, Josh said:

> It sounds like, from the minutes, that some folks would like to see this feature designed differently than it was when it was previously accepted. It wouldn't be the first or last feature to need some design adjustments when lang design met compiler reality. Happy to help with that, so that we can find a design that meets the requirements in the original RFC and any new issues that have arisen since then.

This is about RFC 2102:

https://github.com/rust-lang/rfcs/pull/2102

We discussed this in the meeting on 2024-06-12 without consensus.

Some felt that this was still needed, others first wanted to look for a more minimal approach.

We left this for further discussion.

TC: What do we think?

### "add float semantics RFC" rfcs#3514

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

TC: In addition to documenting the current behavior carefully, this RFC (per RalfJ)...

> says we should allow float operations in `const fn`, which is currently not stable. This is a somewhat profound decision since it is the first non-deterministic operation we stably allow in `const fn`. (We already allow those operations in `const`/`static` initializers.)

TC: What do we think? tmandry proposed this for FCP merge back in October 2023.

### "Tracking Issue for unicode and escape codes in literals" rust#116907

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

TC: nnethercote has implemented most of RFC 3349 ("Mixed UTF-8 literals") and, based on implementation experience, argues that the remainder of the RFC should not be implemented:

> I have a partial implementation of this RFC working locally (EDIT: now at #120286). The RFC proposes five changes to literal syntax. I think three of them are good, and two of them aren't necessary.

TC: What do we think?

### "Proposal: Remove `i128`/`u128` from the `improper_ctypes` lint" lang-team#255

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

TC: Trevor Gross describes the situation:

> For a while, Rust's 128-bit integer types have been incompatible with those from C. The original issue is here [rust-lang/rust#54341](https://github.com/rust-lang/rust/issues/54341), with some more concise background information at the MCP here [rust-lang/compiler-team#683](https://github.com/rust-lang/compiler-team/issues/683)
>
> The current Beta of 1.77 will have [rust-lang/rust#116672](https://github.com/rust-lang/rust/pull/116672), which manually sets the alignment of `i128` to make it ABI-compliant with any version of LLVM (`clang` does something similar now). 1.78 will have LLVM18 as the vendored version which fixes the source of this error.
>
> Proposal: now that we are ABI-compliant, do not raise `improper_ctypes` on our 128-bit integers. I did some testing with abi-cafe and a more isolated https://github.com/tgross35/quick-abi-check during the time https://reviews.llvm.org/D86310 was being worked on, and verified everything lines up. (It would be great to have some fork of abi-cafe in tree, but that is a separate discussion.)
>
> @joshtriplett mentioned that changing this lint needs a lang FCP https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/LLVM.20alignment.20of.20i128/near/398422037. cc @maurer
>
> Reference change from when I was testing [rust-lang/rust@c742908](https://github.com/rust-lang/rust/commit/c742908c4b9abde264b8c5e9663e31c649a47f2f)

TC: Josh nominates this for our discussion. What do we think?

### "`is` operator for pattern-matching and binding" rfcs#3573

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

TC: Josh proposes for us that we should accept:

if an_option is Some(x) && x > 3 {
    println!("{x}");
}

And:

func(x is Some(y) && y > 3);

TC: The main topic discussed in the issue thread so far has been the degree to which Rust should have "two ways to do things". Probably the more interesting issue is how the binding and drop scopes for this should work.

TC: In the 2024-02-21 meeting (with limited attendance), we discussed how we should prioritize stabilizing let chains, and tmandry suggested we may want to allow those to settle first.

TC: What do we think, as a gut check?

### "Unsafe fields" rfcs#3458

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

TC: Nearly ten years ago, on 2014-10-09, pnkfelix proposed unsafe fields in RFC 381:

https://github.com/rust-lang/rfcs/issues/381

On 2017-05-04, Niko commented:

> I am pretty strongly in favor of unsafe fields at this point. The only thing that holds me back is some desire to think a bit more about the "unsafe" model more generally.

Then, in 2023, Jacob Pratt refreshed this proposal with RFC 3458. It proposes that:

> Fields may be declared `unsafe`. Unsafe fields may only be mutated (excluding interior mutability) or initialized in an unsafe context. Reading the value of an unsafe field may occur in either safe or unsafe contexts. An unsafe field may be relied upon as a safety invariant in other unsafe code.

E.g.:

struct Foo {
    safe_field: u32,
    /// Safety: Value must be an odd number.
    unsafe unsafe_field: u32,
}

// Unsafe field initialization requires an `unsafe` block.
// Safety: `unsafe_field` is odd.
let mut foo = unsafe {
    Foo {
        safe_field: 0,
        unsafe_field: 1,
    }
};

On 2024-05-21, Niko nominated this for us:

> I'd like to nominate this RFC for discussion. I've not read the details of the thread but I think the concept of unsafe fields is something that comes up continuously and some version of it is worth doing.

TC: What do we think?

### "RFC: Allow symbol re-export in cdylib crate from linked staticlib" rfcs#3556

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

TC: This seems to be about making the following work:

// kind is optional if it's been specified elsewhere, e.g. via the `-l` flag to rustc
#[link(name="ext", kind="static")]
extern {
    #[no_mangle]
    pub fn foo();

    #[no_mangle]
    pub static bar: std::ffi::c_int;
}

There are apparently use cases for this.

What's interesting is that apparently it already does, but we issue a warning that is wrong:

warning: `#[no_mangle]` has no effect on a foreign function
  --> src/lib.rs:21:5
   |
21 |     #[no_mangle]
   |     ^^^^^^^^^^^^ help: remove this attribute
22 |     pub fn foo_rfc3556_pub_with_no_mangle();
   |     ---------------------------------------- foreign function
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: symbol names in extern blocks are not mangled

TC: One of the author's asks of us is that we don't make this into a hard error (e.g. with the new edition).

TC: What do we think?

### "Better errors with bad/missing identifiers in MBEs" rust#118939

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

TC: The idea here seems to be to improve some diagnostics around `macro_rules`, but this seems to be done by way of reserving the `macro_rules` token more widely, which is a breaking change. Petrochenkov has objected to it on that basis, given that reserving `macro_rules` minimally has been the intention since we hope it will one day disappear in favor of `macro`. What do we think?

### "Uplift `clippy::invalid_null_ptr_usage` lint" rust#119220

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

TC: Urgau proposes this for us:

> This PR aims at uplifting the `clippy::invalid_null_ptr_usage` lint into rustc, this is similar to the [`clippy::invalid_utf8_in_unchecked` uplift](https://github.com/rust-lang/rust/pull/111543) a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one.
>
> ## `invalid_null_ptr_usages`
>
> (deny-by-default)
>
> The `invalid_null_ptr_usages` lint checks for invalid usage of null pointers.
>
> ### Example
>

// Undefined behavior
unsafe { std::slice::from_raw_parts(ptr::null(), 0); }
// Not Undefined behavior
unsafe { std::slice::from_raw_parts(NonNull::dangling().as_ptr(), 0); }

>
> Produces:
>

error: calling this function with a null pointer is undefined behavior, even if the result of the function is unused, consider using a dangling pointer instead
  --> $DIR/invalid_null_ptr_usages.rs:14:23
   |
LL |     let _: &[usize] = std::slice::from_raw_parts(ptr::null(), 0);
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^-----------^^^^
   |                                                  |
   |                                                  help: use a dangling pointer instead: `core::ptr::NonNull::dangling().as_ptr()`

>
> ### Explanation
>
> Calling methods who's safety invariants requires non-null pointer with a null pointer is undefined behavior.
>
> The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a `#[diagnostic]` attribute.

TC: What do we think?

### "Stop skewing inference in ?'s desugaring" rust#122412

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

TC: Waffle nominates this breaking change for us:

> This changes `expr?`'s desugaring like so (simplified, see code for more info):
>
> ```rust
> // old
> match expr {
> Ok(val) => val,
> Err(err) => return Err(err),
> }
>
> // new
> match expr {
> Ok(val) => val,
> Err(err) => core::convert::absurd(return Err(err)),
> }
>
> // core::convert
> pub const fn absurd<T>(x: !) -> T { x }
> ```
>
> This prevents `!` from the `return` from skewing inference:
>
> ```rust
> // previously: ok (never type spontaneous decay skews inference, `T = ()`)
> // with this pr: can't infer the type for `T`
> Err(())?;
> ```

We discussed this on 2024-03-20. On the one hand, people were hesitant to block incremental progress, but on the other, people were hesitant to add a special case if we could address a more general case. There was, I would say, appetite for taking a bigger bite here, but people were uncertain if there were any bigger bites that were feasible other than those discussed to support the never type generally, such as disabling fallback to `()`.

In terms of next steps, we wanted to see an answer about the pros and cons of doing this for `return` generally, which @WaffleLapkin has now [answered](https://github.com/rust-lang/rust/pull/122412#issuecomment-2010480706):

> > it made me wonder whether it would be feasible to change return in general to be a free type variable instead of `!`?
>
> @scottmcm I'm not sure. I don't think it's unfeasible, but it sure is harder than this.
>
> The issues are:
>
> * Need to add fallback for those type variables too, so that `return;` works
> * `{ return; }` (which is currently `!` even though there is `;`) needs to be special cased in a different way
> * Will break strictly more things
>
> I'm not sure if this is a good idea or not. It's kinda weird.

...and we wanted to see the results of the crater run that we know that @WaffleLapkin is working to make happen.

When taking this back up, in addition to those details, we wanted to specifically consider how this incremental step may be addressing known footguns with unsafe code such as that in:

https://github.com/rust-lang/rust/issues/51125

TC: What do we think?

### "panic in a no-unwind function leads to not dropping local variables" rust#123231

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

TC: RalfJ nominates this for us. Consider this code:

#![feature(c_unwind)]

struct Noise;
impl Drop for Noise {
    fn drop(&mut self) {
        eprintln!("Noisy Drop");
    }
}

extern "C" fn test() {
    let _val = Noise;
    panic!("heyho");
}

fn main() {
    test();
}

It doesn't print anything. Should it?

### "Uplift `clippy::double_neg` lint as `double_negation`" rust#126604

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

TC: This proposes to lint against cases like this:

fn main() {
    let x = 1;
    let _b = --x; //~ WARN use of a double negation
}

TC: What do we think?

### "Lang discussion: Item-level `const {}` blocks, and `const { assert!(...) }`" lang-team#251

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

TC: This issue was raised due to discussion in a T-libs-api call. Josh gives the context:

> In discussion of [rust-lang/libs-team#325](https://github.com/rust-lang/libs-team/issues/325) (a proposal for a compile-time assert macro), the idea came up to allow `const {}` blocks at item level, and then have people use `const { assert!(...) }`.
>
> @rust-lang/libs-api would like some guidance from @rust-lang/lang about whether lang is open to toplevel `const { ... }` blocks like this, which would influence whether we want to add a compile-time assert macro, as well as what we want to call it (e.g. `static_assert!` vs `const_assert!` vs some other name).
>
> Filing this issue to discuss in a lang meeting. This issue is _not_ seeking any hard commitment to add such a construct, just doing a temperature check.

CAD97 noted:

> To ensure that it's noted: if both item and expression `const` blocks are valid in the same position (i.e. in statement position), a rule to disambiguate would be needed (like for statement versus expression `if`-`else`). IMO it would be quite unfortunate for item-level `const` blocks to be evaluated pre-mono if that same `const` block but statement-level would be evaluated post-mono.
>
> Additionally: since `const { assert!(...) }` is post-mono (due to using the generic context), it's potentially desirable to push people towards using `const _: () = assert!(...);` (which is pre-mono) whenever possible (not capturing generics).

TC: What do we think?

### "Add lint against function pointer comparisons" rust#118833

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

TC: In the 2024-01-03 call, we developed a tentative consensus to lint against direct function pointer comparison and to push people toward using `ptr::fn_addr_eq`. We decided to ask T-libs-api to add this. There's now an open proposal for that here:

https://github.com/rust-lang/libs-team/issues/323

One question that has come up is whether we would expect this to work like `ptr::addr_eq` and have separate generic parameters, e.g.:

/// Compares the *addresses* of the two pointers for equality,
/// ignoring any metadata in fat pointers.
///
/// If the arguments are thin pointers of the same type,
/// then this is the same as [`eq`].
pub fn addr_eq<T: ?Sized, U: ?Sized>(p: *const T, q: *const U) -> bool { .. }

Or whether we would prefer that `fn_addr_eq` enforced type equality of the function pointers. Since we're the ones asking for this, we probably want to develop a consensus here. We discussed this in the call on 2024-01-10, then we opened a Zulip thread:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Signature.20of.20.60ptr.3A.3Afn_addr_eq.60

TC: On this subject, scottmcm raised this point, with which pnkfelix seemed to concur:

> I do feel like if I saw code that had `fn1.addr() == fn2.addr()` (if `FnPtr` were stabilized), I'd write a comment saying "isn't that what `fn_addr_eq` is for?"
>
> If the answer ends up being "no, actually, because I have different types", that feels unfortunate even if it's rare.
>
> (Like how `addr_eq(a, b)` is nice even if with strict provenance I could write `a.addr() == b.addr()` anyway.)

TC: scottmcm also asserted confidence that allowing mixed-type pointer comparisons is correct for `ptr::addr_eq` since comparing the addresses of `*const T`, `*const [T; N]`, and `*const [T]` are all reasonable. I pointed out that, if that's reasonable, then `ptr::fn_addr_eq` is the higher-ranked version of that, since for the same use cases, it could be reasonable to compare function pointers that return those three different things or accept them as arguments.

TC: Adding to that, scottmcm noted that comparing addresses despite lifetime differences is also compelling, e.g. comparing `fn(Box<T>) -> &'static mut T` with `for<'a> fn(Box<T>) -> &'a mut T`.

TC: Other alternatives we considered were not stabilizing `ptr::fn_addr_eq` at all and instead stabilizing `FnPtr` so people could write `ptr::addr_eq(fn1.addr(), fn2.addr())`, or expecting that people would write instead `fn1 as *const () == fn2 as *const ()`.

TC: Recently CAD97 raised an interesting alternative:

> From the precedent of `ptr::eq` and `ptr::addr_eq`, I'd expect a "`ptr::fn_eq`" to have one generic type and a "`ptr::fn_addr_eq`" to have two. Even if `ptr::fn_eq`'s implementation is just an address comparison, it still serves as a documentation point to call out the potential pitfalls with comparing function pointers.

TC: What do we think?

---

TC: Separately, on the 2024-01-10 call, we discussed some interest use cases for function pointer comparison, especially when it's indirected through `PartialEq`. We had earlier said we didn't want to lint when such comparisons were indirected through generics, but we did address the non-generic case of simply composing such comparisons.

One example of how this is used is in the standard library, in `Waker::will_wake`:

https://doc.rust-lang.org/core/task/struct.Waker.html#method.will_wake

It's comparing multiple function pointers via a `#[derive(PartialEq)]` on the `RawWakerVTable`.

We decided on 2024-01-01 that this case was interesting and we wanted to think about it further. We opened a discussion thread about this:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Function.20pointer.20comparison.20and.20.60PartialEq.60

Since then, another interesting use case in the standard library was raised, in the formatting machinery:

https://doc.rust-lang.org/src/core/fmt/rt.rs.html

What do we think about these, and would we lint on derived `PartialEq` cases like these or no?

### "Implement lint against unexpected unary precedence" rust#121364

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

TC: The proposal is to lint against:

-2.pow(2); // Equals -4.

These would instead be written:

-(2.pow(2)); // Equals -4.

TC: This is a subset of:

https://github.com/rust-lang/rust/pull/117161

...which is also nominated. Whereas the #117161 proposal is to lint on both binary op and unary op cases, this proposal is to lint only on unary op cases. The proposal for this subset came out a discussion with scottmcm.

TC: What do we think?

### "Uplift `clippy::precedence` lint" rust#117161

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

TC: The proposal is to lint against:

-2.pow(2); // Equals -4.
1 << 2 + 3; // Equals 32.

These would instead be written:

-(2.pow(2)); // Equals -4.
1 << (2 + 3); // Equals 32.

Prompts for discussion:

- Is this an appropriate lint for `rustc`?
- How do other languages handle precedence here?
- Is minus special enough to treat differently than other unary operators (e.g. `!`, `*`, `&`)?

### "Should Rust still ignore SIGPIPE by default?" rust#62569

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

TC: Prior to `main()` being executed, the Rust startup code makes a syscall to change the handling of `SIGPIPE`. Many believe that this is wrong thing for a low-level language like Rust to do, because 1) it makes it impossible to recover what the original value was, and 2) means things like `seccomp` filters must be adjusted for this.

It's also just, in a practical sense, wrong for most CLI applications.

This seems to have been added back when Rust had green threads and then forgotten about. But it's been an ongoing footgun.

Making a celebrity appearance, Rich Felker, the author of MUSL libc, notes:

> As long as Rust is changing signal dispositions inside init code in a way that the application cannot suppress or undo, it is _fundamentally unusable to implement standard unix utilities that run child processes_ or anything that needs to preserve the signal dispositions it was invoked with and pass them on to children. Changing inheritable process state behind the application's back is just unbelievably bad behavior and does not belong in a language runtime for a serious language...
>
> As an example, if you implement `find` in Rust, the `-exec` option will invoke its commands with `SIGPIPE` set to `SIG_IGN`, so that they will not properly terminate on broken pipe. But if you just made it set `SIGPIPE` to `SIG_DFL` before invoking the commands, now it would be broken in the case where the invoking user intentionally set `SIGPIPE` to `SIG_IGN` so that the commands would not die on broken pipe.

There was discussion in 2019 about fixing this over an edition, but nothing came of it.

Are we interested in fixing it over this one?

Strawman (horrible) proposal: We could stop making this pre-main syscall in Rust 2024 and have `cargo fix` insert this syscall at the start of every `main` function.

(In partial defense of the strawman, it gets us directly to the arguably best end result while having an automatic semantics-preserving edition migration and it avoids the concerns about lang/libs coupling that Mara raised. The edition migration could add a comment above this inserted code telling people under what circumstances they should either keep or delete the added line.)

### "types team / lang team interaction" rust#116557

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

TC: nikomatsakis nominated this:

> We had some discussion about types/lang team interaction. We concluded a few things:
>
> * Pinging the team like @rust-lang/lang is not an effective way to get attention. Nomination is the only official way to get attention.
> * It's ok to nominate things in an "advisory" capacity but not block (e.g., landing a PR), particularly as most any action can ultimately be reversed. But right now, triagebot doesn't track closed issues, so that's a bit risky.
>
> Action items:
>
> * We should fix triagebot to track closed issues.

TC: What do we think?

### "Match ergonomics 2024" rfcs#3627

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

TC: In the design meeting on 2024-05-15, we discussed Match Ergonomics 2024. We liked what we heard, and people wanted to see this move forward modulo adopting *Option 1* (make `mut x` in inherited patterns an error). This change was made, and in the meeting on 2024-05-24, we resolved the concerns about this.and it moved into FCP.

Since then, tmandry has raised a concern to ask what tradeoffs we're making with the no `ref mut` behind `&` rule. The purpose of this rule is to allow patterns like this:

let &(i, j, [s]) = &(63, 42, &mut [String::from("")]); //~ OK
//~^ i: i32, j: i32, s: &String

One motivation is that there are already cases in patterns where immutability takes precedence over mutability (so it *usually* works). E.g.:

let [a] = &mut &[42]; // x: &i32
let [a] = &&mut [42]; // x: &i32

As the RFC says,

> This change, in addition to being generally useful, makes the match ergonomics rules more consistent by ensuring that immutability *always* takes precedence over mutability.

The main drawback seems to be that, with this rule, one cannot:

> ...consistently write a `&mut` pattern that matches an inherited reference regardless of whether the binding mode has been converted to `ref` by an outer `&` so long as there is a `&mut` type involved.

That is, this is allowed:

//@ edition: 2024
let  [[&mut x]] = [&mut [42]]; //~ OK, x: i32

(Because the `ref mut` is not behind an `&`.)

But these are not:

//@ edition: 2024
let &[[&mut x]] = &[&mut [42]]; //~ ERROR
let  [[&mut x]] = &[&mut [42]]; //~ ERROR

(Because the `ref mut` is behind an `&`.)

However, one can write, and is intended to write, these instead:

//@ edition: 2024
let  [[&x]] =  [&mut [42]]; //~ OK
let &[[&x]] = &[&mut [42]]; //~ OK
let  [[&x]] = &[&mut [42]]; //~ OK

These take advantage of the fact that `&` matches `&mut`. The reason that `&` matching `&mut` was included in this RFC (rather than e.g. being deferred to future work) was for explicitly this reason.

---

TC: Separately, tmandry writes:

>> Everything in this RFC, including the migration lint, is either already in nightly under an experimental feature gate, or waiting on PR review.
>
> Fantastic, thanks for your efforts here. Ideally I would like to see this go in as part of the unstable 2024 edition once this RFC lands, i.e. not blocking on a stabilization FCP before that happens.

TC: Does this sound right to us?

### "[RFC] `core::marker::Freeze` in bounds" rfcs#3633

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

TC: There's now a proposal on the table for the stabilization of the `Freeze` trait in bounds.

TC: We'll probably need to schedule a design meeting to work through this.

### "RFC: Return Type Notation" rfcs#3654

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

TC: Niko has now posted the long-awaited RFC for RTN in bounds and where clauses.

> Return type notation (RTN) gives a way to reference or bound the type returned by a trait method. The new bounds look like `T: Trait<method(..): Send>` or `T::method(..): Send`. The primary use case is to add bounds such as `Send` to the futures returned by `async fn`s in traits and `-> impl Future` functions, but they work for any trait function defined with return-position impl trait (e.g., `where T: Factory<widgets(..): DoubleEndedIterator>` would also be valid).
>
> This RFC proposes a new kind of type written `<T as Trait>::method(..)` (or `T::method(..)` for short). RTN refers to "the type returned by invoking `method` on `T`".
>
> To keep this RFC focused, it only covers usage of RTN as the `Self` type of a bound or where-clause. The expectation is that, after accepting this RFC, we will gradually expand RTN usage to other places as covered under [Future Possibilities](#future-possibilities). As a notable example, supporting RTN in struct field types would allow constructing types that store the results of a call to a trait `-> impl Trait` method, making them [more suitable for use in public APIs](https://rust-lang.github.io/api-guidelines/future-proofing.html).

TC: We'll probably need to schedule a design meeting to work through this.

### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418

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

TC: We discussed this last in the meeting on 2024-03-13. scottmcm has now raised on concern on the issue and is planning to make a counter-proposal:

> I remain concerned about exposing this with no opt-out on an unrestricted generic type @rfcbot concern overly-broad
>
> I'm committing to making an alternative proposal because I shouldn't block without one. Please hold my feet to the fire if that's no up in a week.
>
> Basically, I have an idea for how we might be able to do this, from [#106418 (comment)](https://github.com/rust-lang/rust/pull/106418#issuecomment-1698887324)
>
> > 2. Expose the variant ordering privately, only accessible by the type owner/module.
> >
> > Solution 2. is obviously more desirable, but AFAIK Rust can't do that and there is no proposal to add a feature like that.

https://github.com/rust-lang/rust/pull/106418#issuecomment-1994833151

### "Fallout from expansion of redundant import checking" rust#121708

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

TC: We discussed this in the meeting on 2024-03-13. The feelings expressed included:

- We don't want to create a perverse incentive for people to expand existing lints rather than to create new ones where appropriate just because there's less process for expanding the meaning of an existing lint.
- It would be good if potentially-disruptive expansions of an existing lint either:
- Had a machine-applicable fix.
- Or had a new name.
- We don't want to require a new lint name for each expansion.
- We don't want to require a crater run for each change to a lint.
- There are two ways to prevent disruption worth exploring:
- Prevent potentially-disruptive changes from hitting master.
- Respond quickly to early indications of disruption once the changes hit master.
- Compiler maintainers have a sense of what might be disruptive and are cautious to avoid it. It may be OK to have a policy that is not perfectly measurable.

TC: tmandry volunteered to draft a policy proposal.

### "What are the guarantees around which constants (and callees) in a function get monomorphized?" rust#122301

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

TC: The8472 asks whether this code, which compiles today, can be relied upon:

const fn panic<T>() {
    struct W<T>(T);
    impl<T> W<T> {
        const C: () = panic!();
    }
    W::<T>::C
}

struct Invoke<T, const N: usize>(T);

impl<T, const N: usize> Invoke<T, N> {
    const C: () = match N {
        0 => (),
        // Not called for `N == 0`, so not monomorphized.
        _ => panic::<T>(),
    };
}

fn main() {
    let _x = Invoke::<(), 0>::C;
}

The8472 notes that this is a useful property and that there are use cases for this in the compiler and the standard library, at least unless or until we adopt something like `const if`:

https://github.com/rust-lang/rfcs/issues/3582

RalfJ has pointed out to The8472 that the current behavior might not be intentional and notes:

> It's not opt-dependent, but it's also unclear how we want to resolve the opt-dependent issue. Some [proposals](https://github.com/rust-lang/rust/issues/122814#issuecomment-2015090501) involve also walking all items "mentioned" in a const. That would be in direct conflict with your goal here I think. To be clear I think that's a weakness of those proposals. But if that turns out to be the only viable strategy then we'll have to decide what we want more: using `const` tricks to control what gets monomorphized, or not having optimization-dependent errors.
>
> One crucial part of this construction is that everything involved is generic. If somewhere in the two "branches" you end up calling a monomorphic function, then that may have its constants evaluated even if it is in the "dead" branch -- or it may not, it depends on which functions are deemed cross-crate-inlinable. That's basically what #122814 is about.

TC: The question to us is whether we want to guarantee this behavior. What do we think?

### "Policy for lint expansions" rust#122759

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

TC: In the call on 2024-03-13, we discussed this issue raised by tmandry:

"Fallout from expansion of redundant import checking"

https://github.com/rust-lang/rust/issues/121708

During the call, the thoughts expressed included:

- We don't want to create a perverse incentive for people to expand existing lints rather than to create new ones where appropriate just because there's less process for expanding the meaning of an existing lint.
- It would be good if potentially-disruptive expansions of an existing lint either:
- Had a machine-applicable fix.
- Or had a new name.
- We don't want to require a new lint name for each expansion.
- We don't want to require a crater run for each change to a lint.
- There are two ways to prevent disruption worth exploring:
- Prevent potentially-disruptive changes from hitting master.
- Respond quickly to early indications of disruption once the changes hit master.
- Compiler maintainers have a sense of what might be disruptive and are cautious to avoid it. It may be OK to have a policy that is not perfectly measurable.

TC: tmandry volunteered to draft a policy proposal. He's now written up this proposal in this issue.

> ## Background
>
> When a lint is expanded to include many new cases, it adds significant complexity to the rollout of a toolchain to large codebases. Maintainers of these codebases are stuck with the choice of
>
> 1. Disabling the existing lint while the toolchain is updated and new cases are fixed
> 2. Fixing cases manually and updating the toolchain immediately
>
> Both of these come with the problem of _racing_ with other developers in a codebase who may land new code which triggers the expanded lint in a new compiler, but does _not_ trigger the lint in an old compiler.
>
> While it would be nice to solve this "raciness" once and for all, there are other considerations at play. Instead, we propose to support these users by either providing them with a new lint name to temporarily opt out of _OR_ a machine-applicable fix which eases the pain of any races which might occur.
>
> Note that this requirement only applies to _significant_ lint expansions as measured by crater.
>
> ## Policy
>
> When an existing lint is expanded to include many new cases, we must provide either:
>
> 1. A new lint name under the existing group, so that users may opt out of the expansion at least temporarily, or
> 2. A MachineApplicable fix for the lint.
>
> Exceptions to this policy may be made via Language Team FCP.
>
> Here, we define "many new cases" as impacting more than 5% of the top-1000 crates on crates.io. This can be measured by counting the number of regressions from a crater run like the one below.
>
> A crater run is not required before landing for every lint expansion. Reviewers should use their best judgment to decide if one is required. However, if a lint expansion lands that violates this requirement, or is strongly suspected to violate this requirement based on other impact, it should be reverted.
>
> #### Crater command
>
> To measure the impact of a lint as defined by this policy, you can use the following crater command:
>
> `@craterbot run name=<name> start=master#<hash1>+rustflags=-D<lint_name> end=master#<hash2>+rustflags=-D<lint_name> crates=top-1000 mode=check-only p=1`
>
> See the [crater docs](https://github.com/rust-lang/crater/blob/master/docs/bot-usage.md#tutorial-creating-an-experiment-for-a-pr) for more information.

TC: What do we think?

### "Tracking Issue for externally implementable items" rust#125418

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

TC: We reviewed in triage an RFC for externally implementable functions on 2024-05-22 along with a companion/alternative RFC for externally implementable statics. That discussion produced two more proposals, one from Amanieu and one from tmandry.

TC: We're likely going to need a design meeting to work through these.

## Action item review

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

## Pending lang team project proposals

None.

## PRs on the lang-team repo

### "Add soqb`s design doc to variadics notes" lang-team#236

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

### "Update auto traits design notes with recent discussion" lang-team#237

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

### "Update hackmd link to a public link" lang-team#258

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

### "Adding a link to "how to add a feature gate" in the experimenting how-to" lang-team#267

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

## RFCs waiting to be merged

### "RFC: Return Type Notation" rfcs#3654

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

## `S-waiting-on-team`

### "Reorder trait bound modifiers *after* `for<...>` binder in trait bounds" rust#127054

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

### "warn less about non-exhaustive in ffi" rust#116863

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

### "offset_from: always allow pointers to point to the same address" rust#124921

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

### "Don't make statement nonterminals match pattern nonterminals" rust#120221

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

### "Initial support for auto traits with default bounds" rust#120706

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

### "Stabilize `count`, `ignore`, `index`, and `length` (`macro_metavar_expr`)" rust#122808

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

### "Better errors with bad/missing identifiers in MBEs" rust#118939

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

### "Rename `AsyncIterator` back to `Stream`, introduce an AFIT-based `AsyncIterator` trait" rust#119550

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

### "Allow `#[deny]` inside `#[forbid]` as a no-op" rust#121560

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

### "Fixup Windows verbatim paths when used with the `include!` macro" rust#125205

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

## Proposed FCPs

**Check your boxes!**

### "Async closures" rfcs#3668

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

### "Guard Patterns" rfcs#3637

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

### "`repr(discriminant = ...)` for type aliases" rfcs#3659

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

### "Stabilize `count`, `ignore`, `index`, and `length` (`macro_metavar_expr`)" rust#122808

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

### "Supertrait item shadowing v2" rfcs#3624

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

### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378

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

### "add float semantics RFC" rfcs#3514

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

### "[RFC] externally implementable functions" rfcs#3632

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

### "Match ergonomics 2024" rfcs#3627

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

### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418

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

### "Policy for lint expansions" rust#122759

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

### "RFC: inherent trait implementation" rfcs#2375

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

### "Don't allow unwinding from Drop impls" rfcs#3288

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

### "Add text for the CFG OS Version RFC" rfcs#3379

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

### "Add support for `use Trait::func`" rfcs#3591

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

### "[RFC] Add `#[export_ordinal(n)]` attribute" rfcs#3641

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

### "Tracking Issue for nested field access in offset_of" rust#120140

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

### "Tracking Issue for enum access in offset_of" rust#120141

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

### "Stabilize associated type position impl Trait (ATPIT)" rust#120700

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

### "regression: let-else syntax restriction (right curly brace not allowed)" rust#121608

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

## Active FCPs

### "Deny keyword lifetimes pre-expansion" rust#126762

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

### "Tracking Issue for `const_cstr_from_ptr`" rust#113219

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

### "Bump `elided_lifetimes_in_associated_constant` to deny" rust#124211

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

### "Tracking issue for function attribute `#[coverage]`" rust#84605

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

### "Don't make statement nonterminals match pattern nonterminals" rust#120221

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

### "RFC: #[derive(SmartPointer)]" rfcs#3621

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

### "Allow `#[deny]` inside `#[forbid]` as a no-op" rust#121560

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

## P-critical issues

None.