---
title: Triage meeting 2023-05-09
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-05-09

## Attendance

* Team members: nikomatsakis
* Others:

## Meeting roles

* Action item scribe:
* Note-taker:

## Scheduled meetings

* May 10 -- ~~Language design principles~~
* nikomatsakis: doubt I have time to prepare this. Canceling.
* May 17 -- RPITIT stabilization discussion
* May 24 -- Keyword generics initaitive
* "associated return type" instead
* May 31 -- TAIT defining scope options

## Announcements or custom items

### RPITIT

The [RPITIT RFC](https://github.com/rust-lang/rfcs/pull/3425) is posted. I'd like to move quickly, but there are also some interesting (negative) comments that are worth reading. Oh, right, we scheduled a meeting for this.

### RTN proposal

Repurpose May 24 to discuss Associated Return Type proposal?

OK, let's do that, it seems more urgent.

## Action item review

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

## Pending lang team project proposals

None.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## `S-waiting-on-team`
### "Tracking issue for dyn upcasting coercion" rust#65991

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

WaffleLapkin is working towards a debug flag to try and gather data. Let's give them some time to do that.

Would be nice if we could set a reminder.

### "Remove misleading target feature aliases" rust#107707

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

FCP in progress.

### "expand: Change how `#![cfg(FALSE)]` behaves on crate root" rust#110141

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

FCP in progress, but includes compiler team?

Changed to lang team.

## Proposed FCPs

**Check your boxes!**
### "unsafe attributes" rfcs#3325

- **Link:** https://github.com/rust-lang/rfcs/pull/3325
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911253):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * ~~change-syntax-to-drop-parentheses~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974
> * ~~maybe-make-this-part-of-next-edition~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458690311
> * syntax-not-ideal (https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911218):
> @rfcbot merge

Last week talked about [syntax](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1532012274).

lokathor: Discussion points out that this example doesn't "meaningfully" improve the situation. It just has the word unsafe here and there but doesn't make it more plausible for you to truly guarantee safety. e.g., library authors just aren't in a position to do that.

joshtriplett: I understand what you're getting at, but there's a point where you've said, "I've done my part, I've documented what I'm doing, still possible for linker to screw with me". Still seems like a net improvement. Less saying "I know I've made it safe under all possible circumstances" and more "I understand the obligation I'm talking on, and I'm doing my part to avoid breaking it". Outside world can do weird things.

lokathor: RFC would be stronger if it let you enumerate symbols and things.

nikomatsakis: if it detected conflicts, it'd just be safe?

lokathor: can't detect all conflicts.

scottmcm: this says to me that the linking/library-loading are the unsafe parts, no-mangle isn't unsafe.

joshtriplett: if I define a function `foo` in my crate, I can also link the program, add that symbol, and cause problems.

... *ed: spaced out a bit*

pnkfelix: hashed symbols are significantly less likely to hit conflicts

joshtriplett: with unsafe, we try to make it impossible to have UB, even when somebody is out to get you

joshtriplett: what other attributes?

lokathor: no-mangle, link-section come to mind. Both give obligations to linker interaction. I think a better version to handle this would be to create a system where that information gets bubbled up.

nikomatsakis: has anybody hit this with a real world Rust program?

joshtriplett: I mean yes, but it's documented.

nikomatsakis: feels like a lot of work for a pretty theoretical problem.

scottmcm: what josh just said there, using a library incurs an obligation, not sure that putting unsafe on no-mangle helps people use it correctly.

joshtriplett: I think no-mangle is unsafe. They should have to say I'm not doing screwy things with it.

nikomatsakis: two points.

* I think that discharging the unsafe obligation through docs seems valid, and forcing you to write unsafe at least makes you aware you would need to do something.
* Are there other attributes that would need unsafe? e.g., maybe something to declare a trusted?

lokathor: all the other examples I see https://github.com/rust-lang/rust/issues/82499 are from linker. And I'm concerned about transitive usage.

nikomatsakis: yes but I'm just saying that seems orthogonal, we can say that something is unsafe, and then also have a cargo tool that gives you the transitive no-mangle symbols from your dependencies.

nikomatsakis: what about those links where people overwrite `main` with static or whatever? those go around every few years.

lokathor: rfcs is good, but there is more work to do to properly handle no-mangle

joshtriplett: I think adding that as future work makes sense. Perhaps send a suggestion to Ralf for that?

lokathor to send a GH suggestion.

### "RFC: UTF-8 characters and escape codes in (byte) string literals" rfcs#3349

- **Link:** https://github.com/rust-lang/rfcs/pull/3349
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747916):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
> * waiting-on-update-re-using-char-and-string-tables (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1503875165)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889):
> I do think we should permit `br"¥¥¥"`, but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.
>
> I'm going to go ahead and propose FCP for this. This does *not* preclude making further changes to how this information is presented.
>
> @rfcbot merge
>
> @rfcbot concern raw-byte-strings-with-unicode

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

- **Link:** https://github.com/rust-lang/rfcs/pull/3355
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1513641410):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1513641387):
> @rfcbot fcp merge
>
> We talked about this in the lang team triage meeting and agreed that this is ultimately a council-level decision. That said, it seems like a good idea to get formal lang team buy-in ahead of the council making a decision on this.
>
> Since we can do that now while the council is still forming, I'm opening an FCP for it. **Note that this will still need a _separate_ FCP to actually be merged once the governance council is formed.**

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

- **Link:** https://github.com/rust-lang/rfcs/pull/3368
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729113):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @Aaron1011
> * [x] @cjgillot
> * [x] @davidtwco
> * [x] @eddyb
> * [x] @estebank
> * [x] @joshtriplett
> * [x] @lcnr
> * [x] @matthewjasper
> * [x] @michaelwoerister
> * [ ] @nagisa
> * [x] @nikomatsakis
> * [x] @oli-obk
> * [x] @petrochenkov
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @tmandry
> * [x] @wesleywiser
>
> Concerns:
>
> * doesnt-pull-its-weight (https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1514914043)
> * is-attribute-namespace-tool-module (https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1514908284)
> * ~~lang-team-signoff~~ resolved by https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1528150248
> * ~~translation~~ resolved by https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1511696325
> * ~~version-namespace~~ resolved by https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1528150248
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729088):
> @rfcbot merge
>
> I think we should merge this RFC, modulo some concerns I note below.
>
> It would be good to merge it soon so we can get the `#[diagnostic]` namespace parsed by rustc, so any crate using it in the future won't have to bump its MSRV past the first rustc version that knows about `#[diagnostic]` (even if it doesn't support any attributes yet – unknown attributes are allowed to be no-ops in the RFC).
>
> ## Concerns
>
> @rfcbot concern version-namespace
>
> I personally think we should not include the version namespace in the current proposal but include it as a future possibility. @oli-obk pointed out to me that we can always decide to include a version namespace later, and choose to require it in a new edition if we decide that it was a mistake to let you use a diagnostic attribute _without_ a version. However, I think we should choose the more ergonomic option for now.
>
> This doesn't necessarily represent the whole lang team's opinion (sorry for churn around that), but I'll try to push on getting consensus here.
>
> @rfcbot concern lang-team-signoff
>
> Several members of the lang team don't necessarily want to bypass the lang team for the stabilization process, though I'm sympathetic to the argument that there could be too much high-frequency churn and don't want the lang team to get in the way of progress. I propose modifying the RFC to say that the lang team can choose to adopt an expedited process for stabilization of new attributes and fields with an FCP (this would not require a new RFC).
>
> ## Additional feedback
>
> I think it would be ideal to strengthen the wording around warning on unrecognized lints or fields. I think these should _always_ be a warn-by-default lint.
>
> We may want to make it possible for a diagnostic attribute to affect or create new warn-by-default lints, which by my read is not allowed in the current RFC ("Any attribute in this namespace may... only affect the messages emitted by a compiler in case of a failed compilation.")
>
> Personally I think it's reasonable to allow affecting existing warnings in the current RFC, and leave the creation of new ones as a future possibility. Or if either of these were considered and rejected, the RFC should say why.

### "Return position `impl Trait` in traits" rfcs#3425

- **Link:** https://github.com/rust-lang/rfcs/pull/3425
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3425#issuecomment-1531916403):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3425#issuecomment-1531916376):
> @rfcbot fcp merge
>
> This feature has been a long time coming and feels like a no brainer to me. I'm going to start the merge proceedings.

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

- **Link:** https://github.com/rust-lang/rust/issues/63063
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/63063#issuecomment-1360043090):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * ~~~~ resolved by https://github.com/rust-lang/rust/issues/63063#issuecomment-1361432898
> * docs (https://github.com/rust-lang/rust/issues/63063#issuecomment-1364525286)
> * function-defining-uses (https://github.com/rust-lang/rust/issues/63063#issuecomment-1385946789)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/63063#issuecomment-1360043060):
> @rfcbot fcp merge
>
> This has been a long-time coming. Let's Do This!
>
> [Stabilization report in this comment.](https://github.com/rust-lang/rust/issues/63063#issuecomment-1354392317)

### "Stabilise inline_const" rust#104087

- **Link:** https://github.com/rust-lang/rust/pull/104087
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231887):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * ~~expectations-around-panics-in-inline-const~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210
> * optimization-dependent-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210)
> * ~~post-monomorphization-errors~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1448730779
> * should-unused-code-cause-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1410921524)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231871):
> Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
>
> @rfcbot fcp merge

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

- **Link:** https://github.com/rust-lang/rust/pull/107378
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287200):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
> * why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287177):
> We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:
>
> @rfcbot merge
>
> We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.

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

- **Link:** https://github.com/rust-lang/rust/issues/107645
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1468728438):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * explicit-alternative (https://github.com/rust-lang/rust/issues/107645#issuecomment-1469979788)
> * why-not-just-the-return-type (https://github.com/rust-lang/rust/issues/107645#issuecomment-1468796621)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1468728409):
> @rfcbot fcp merge
>
> I propose that we accept https://github.com/rust-lang/rust/pull/107809. It implements a conservative path forward. Basically any function that constraints a TAIT but doesn't list the TAIT in its arguments/return type is a hard error, giving us room to change the behavior in the future.
>
> ### Final behavior as I understand it
>
> * A TAIT has a *defining scope* that corresponds to the enclosing module or item.
> * A *defining use* for a TAIT is any item that (a) is within the defining scope and (b) contains a function that lists the TAIT in the argument or return types, either before or after normalization (*see edge case below).
> * Within the defining scope, an item is called *constraining* if it puts constraints on the value of the TAIT. i.e., for the item to type check, the hidden type of the TAIT must have a particular value. This could occur because of a `let` (e.g., `let x: TAIT = 22_u32`), a return (e.g., `return 22_u32` in a function whose return type is `TAIT`), or in other ways.
> * Any *constraining* item within the defining scope that is not a *defining use* is a hard error. This means we can later opt to allow such a use; or to allow it with an annotation of some kind; or to make other such changes.
> * All *defining uses* must fully infer the hidden type of the TAIT and must infer the same type for the TAIT.
> * WIthin the defining scope, TAITs must always be given generic arguments (e.g., `fn foo<T>() -> TAIT<T>` and not `fn foo() -> TAIT<u32>`). This ensures inference is tractable and well-defined.
>
> ### Current bugs and limitations (forwards compatible to change)
>
> * Within the defining scope, attempts to check whether `TAIT` implements an auto-trait will yield a cycle error unless the auto-trait is listed in the TAIT's bounds. This is suboptimal, but the ideal fix is unclear.
> * A function that has an argument which is an associated type referencing a TAIT (e.g. `<TAIT as SomeTrait>::SomeItem`) ought to be considered a *defining use*. However, in the compiler today, if that associated type can be normalized, and the normalized form does not reference the TAIT, the function is not. This can only cause more errors.
>
> @rustbot labels -I-lang-nominated

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

- **Link:** https://github.com/rust-lang/rust/pull/108782
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108782#issuecomment-1468627626):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * types-team-input (https://github.com/rust-lang/rust/pull/108782#issuecomment-1477170467)
> * unclear-motivation (https://github.com/rust-lang/rust/pull/108782#issuecomment-1522295931)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/108782#issuecomment-1468627594):
> @rfcbot fcp merge
>
> Discussed in a (minimally attended) lang-team triage meeting and we are in favor of moving forward with this.
>

### "expand: Change how `#![cfg(FALSE)]` behaves on crate root" rust#110141

- **Link:** https://github.com/rust-lang/rust/pull/110141
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/110141#issuecomment-1531951914):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @Aaron1011
> * [x] @cjgillot
> * [ ] @davidtwco
> * [ ] @eddyb
> * [ ] @estebank
> * [ ] @joshtriplett
> * [x] @lcnr
> * [x] @matthewjasper
> * [ ] @michaelwoerister
> * [ ] @nagisa
> * [x] @nikomatsakis
> * [x] @oli-obk
> * [x] @petrochenkov
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
> * [x] @wesleywiser
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/110141#issuecomment-1531951861):
> @rfcbot fcp merge
>
> Discussed in @rust-lang/lang meeting and we felt that this change was consistent with other behavior at crate root. Moving to merge.

## Active FCPs
### "Remove misleading target feature aliases" rust#107707

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Explicit Tail Calls" rfcs#3407

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

joshtriplett: I had a bunch of comments and back-and-forth that amounted to "I don't think we should spell this with a brand new keyword that doesn't include `return`". Not intended to be an objection to block experimentation. Something to consider before stabilization. Really appreciating the comment of "don't make demo look done". Somebody suggested what if we just make this `explicit_tail_call`. As in, rather than having a keyword like `become`, it could be `return explicit_tail_call` or `#[explicit_tail_call] return`.

nikomatsakis: `k#become`?

scottmcm: I think we should say the syntax is an unresolved question? Also, become is reserved, so we don't need `k#become`.

joshtriplett: I do think that the premise of "don't make the demo look done" is important. Based on experience from async-await. I think it we ship this with `become`, people will use it and think of it as the final syntax. My concern is that "willing to use this as experiment" does not provide evidence.

TC: haven't Rust users been waiting for that keyword?

joshtriplett: A very small subset of Rust users is, but most have no idea what that is.

lokathor: I didn't know it was a keyword at all.

nikomatsakis: I wonder if we should do this as an experiment. Rather than calling it an RFC with an unresolved question, I'd be more inclined to do it as an experiment, and author an RFC when we know the keyword we want.

scottmcm: questions that are semantically most important will easily get drowned by the choice of keyword. The part of RFC that has blocked it from happening for years is "what exactly are the restrictions that will ensure them". If the RFC says backend is responsible, it's going to be must-tail

TC: it was blocked on LLVM support, which is now better

scottmcm: I thought must-tail worked, but only on some LLVM backends.

nikomatsakis: I would hope that the experiment would work out those questions too, not just slap a "must-tail" and call it done. It seems like the key questions are (1) how will users see it; (2) how will we manage destructors; (3) what is the limitations on back-ends.

scottmcm: we are confident enough that we want it that we are want to see it implemented, people can see how it works on different backends, one of the thing that the RFC would need to define is "here is why the restrictions will be sufficient".

nikomatsakis: I would think that the experiment would be helpful for e.g. getting it to work on cranelift, or try it with emscripten.

TC: clang has this attribute, so we can reference what restrictions they've put on there.

### "Remove misleading target feature aliases" rust#107707

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

removing nomination.

### "Make pointer_structural_match lint warn by default" rust#110166

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

Discussed in meeting:

* We don't want to do a forwards-compatibility warning unless we have a firm plan to deprecate.
* Not opposed to doing fowrads compatibility warning at some point.
* Let's do warn for now.

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

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

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

### "Support RISC-V unaligned-scalar-mem target feature" rust#110884

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

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

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