owned this note
owned this note
Published
Linked with GitHub
---
title: Triage meeting 2023-08-01
tags: triage-meeting
url: https://hackmd.io/eEpxNWhQTauw9LzsrZqBkQ
---
# T-lang meeting agenda
* Meeting date: 2023-08-01
## Attendance
* Team members: Josh, Scott, Felix
* Others: TC, Lokathor, David
## Meeting roles
* Action item scribe:
* Minutes: TC
## Scheduled meetings
- "Capturing lifetimes in `impl Trait`" [#215](https://github.com/rust-lang/lang-team/issues/215)
Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.
## Announcements or custom items
(Meeting attendees, feel free to add items here!)
## Action item review
* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)
## Pending lang team project proposals
None.
## PRs on the lang-team repo
### "Frequently requested changes: `return expr if condition`" lang-team#213
**Link:** https://github.com/rust-lang/lang-team/pull/213
TC: The FCP merge is complete. It seems this can be merged.
## 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
TC: Two weeks ago we agreed to proceed to an FCP if no data had been provided. We made a public request for data to this effect.
TC: Last week, we reviewed the data provided. It was mostly not surprising, but it led to discussion. We seemed open to an opt-out at the trait level and/or LTO or other compile-time options to control this.
TC: We discussed whether we should block on these options. It's technically an API breaking change for a crate to later opt-out a trait. But does it matter? We're already paying for this size increase in practice; the question here is whether to commit to it.
TC: One option discussed was to create an experiment for disabling this at the trait level. Then, if there proved demand for it, we could RFC and stabilize the experiment. @nikomatsakis was going to reach out to charleslf about this.
TC: Whether to continue moving forward without that option available seemed to be an open question.
TC: In the last week, @WaffleWapkin has posted an [interesting issue](https://github.com/rust-lang/rust/issues/114007) that reports that VTables include certain uncallable methods: "This is especially sub-optimal in the presence of trait upcasting, since this makes otherwise empty (wrt to trait objects) traits non-empty, adding need for more vptrs."
TC: Seems to be waiting on @nikomatsakis; no new action this meeting.
### "Create `unnecessary_send_constraint` lint for `&(dyn ... + Send)`" rust#110961
**Link:** https://github.com/rust-lang/rust/pull/110961
TC: The FCP merge is complete, but we're waiting on the author to make some final updates. We removed the nomination, but not the `S-waiting-on-team`.
### "Replace old private-in-public diagnostic with type privacy lints" rust#113126
**Link:** https://github.com/rust-lang/rust/pull/113126
TC: Last week we decided to move forward with this and started an FCP merge. It has three boxes checked.
TC: @nikomatsakis saw that the author had started a crater run. @nikomatsakis filed a concern based on this to check with the author that no backward-incompatible behavior was expected. The author has since [responded](https://github.com/rust-lang/rust/pull/113126#issuecomment-1650522718) to confirm that indeed no backward incompatible behavior is expected. In terms of why crater was used, the author responded that, "I wanted to check that all the effective visibility tables are filled correctly and nothing unexpected happens, since crater runs are pretty cheap now." Based on this, the concern should probably be removed.
TC: This meeting: we're waiting on @nikomatsakis to remove his concern.
## 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
TC: This seems to be blocked on a concern about the syntax, but we've also discussed lingering questions about the degree to which this is a good idea at all. The basic concerns can be summarized as:
- At the function level, `unsafe` provides both a way to create an obligation (`unsafe fn`) and a way to discharge an obligation (`unsafe { .. } `).
- These are often paired; if you use `unsafe { .. }` but cannot fully discharge the obligation within that function, you make it an `unsafe fn` to propagate the obligation upward.
- The `unsafe(..)` in unsafe attributes seemingly does both. It can be read as, on the one hand, discharging the obligation created by, e.g. `no_mangle`, but on the other, it can't actually discharge that obligation without creating a new upward obligation.
- But there's no syntactic way to discharge *this* obligation.
- What we've been saying is that "the obligation is discharged by documenting it", but if this new syntax is going to create a stronger association between attributes and `unsafe`, is this really what we want to be encouraging about how `unsafe` is handled and how its obligations should be discharged?
- (With respect to `unsafe fn`, documenting the invariants that must be upheld is what is needed so that the *caller* can appropriately discharge the obligation, but documenting it does not in and of itself discharge any obligations.)
Josh: Seems we may be blocked on figuring out the syntax. Maybe we should review the options here in a consolidated way.
Josh: We may want to move forward with this give the 2024 edition, as we could then require this.
### "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
TC: This is waiting on the author.
### "Allow cfg-attributes in where clauses" rfcs#3399
- **Link:** https://github.com/rust-lang/rfcs/pull/3399
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3399#issuecomment-1640750937):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @tmandry
>
> 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/3399#issuecomment-1640750790):
> @rfcbot merge
TC: We decided this two weeks ago and decided it was a good idea. It's waiting on boxes to be checked.
### "Tracking issue for the `thiscall` calling convention" rust#42202
- **Link:** https://github.com/rust-lang/rust/issues/42202
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/42202#issuecomment-1616187726):
> Team member @petrochenkov has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Aaron1011
> * [x] @cjgillot
> * [x] @compiler-errors
> * [x] @davidtwco
> * [x] @eddyb
> * [x] @estebank
> * [ ] @jackh726
> * [ ] @lcnr
> * [x] @matthewjasper
> * [x] @michaelwoerister
> * [ ] @nagisa
> * [x] @oli-obk
> * [x] @petrochenkov
> * [ ] @pnkfelix
> * [ ] @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/issues/42202#issuecomment-1616187723):
> @rfcbot fcp merge
> Stabilization report: https://github.com/rust-lang/rust/issues/42202#issuecomment-1565207948
TC: T-lang has done what it needed to do here.
### "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
Looks like our comments on <https://github.com/rust-lang/rust/pull/112879#issuecomment-1641214618> are still relevant, nothing new.
scottmcm: We may be OK to move forward here; we discussed that we wanted this. Maybe we just need to resolve our concerns.
Lokathor: Dylan-DPC marked it as blocked on https://github.com/rust-lang/rust/issues/86730
(discussion about what we're actually blocked on, and that there may be unrelated things at play....)
Josh: Maybe write a comment to ask whether this should really be blocked on those other issues?
scottmcm: My guess: This would stabilize a new thing in expression starts.
scottmcm: This applies to `async` blocks as well?
scottmcm: Is this an existing problem that is true of other expression constructs?
David: It does not apply to `async`.
Lokathor: Should this go on the list of things to handle in 2024, give the divergence in the macro matcher? There's been a bullet point suggestion to fix this in 2024.
Josh: That seems appropriate to dig into. Is that currently present in our document of things to look into for 2024?
pnkfelix: It has the right label on it.
### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378
- **Link:** https://github.com/rust-lang/rust/pull/107378
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287200):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
> * why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287177):
> We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:
>
> @rfcbot merge
>
> We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.
### "TAIT defining scope options" rust#107645
- **Link:** https://github.com/rust-lang/rust/issues/107645
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789843):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * encapsulation-is-too-powerful (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
> * nested-modules-can-always-define-but-nested-functions-cannot (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789814):
> @rfcbot fcp merge
>
> We held a design meeting yesterday where we reviewed [this document](https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2023-05-31-TAIT-stabilization.md) prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.
>
> The document proposed the following resolution to this issue:
>
> - The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
> - Functions and methods must have the hidden type that they intend to constrain within their signature -- within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
> - Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
> - A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
> - The hidden type may be constrained by functions, methods, constants, and statics.
>
> The doc goes into more detail about the justifications and alternatives.
>
> Given all this, I propose to merge and accept this proposal.
### "Lower `Or` pattern without allocating place" rust#111752
- **Link:** https://github.com/rust-lang/rust/pull/111752
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/111752#issuecomment-1641010420):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/111752#issuecomment-1641010396):
> Thanks for the summary, @cjgillot !
>
> I think lowering short-circuiting operators as control flow makes good sense, and fits well with future potential for things like let chains or scoping for an `is` operator. This does suggest that if we ever allow overriding them then those overrides ought to work via control-flow as well, but I don't see that as blocking anything that we'd need. (For example, we could still lower the LHS to a call that returns an `Option`, and have the lowering work on that `Option`.)
>
> @rfcbot merge
### "Replace old private-in-public diagnostic with type privacy lints" rust#113126
- **Link:** https://github.com/rust-lang/rust/pull/113126
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/113126#issuecomment-1650352539):
> 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
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * backwards-incompat (https://github.com/rust-lang/rust/pull/113126#issuecomment-1650355872)
>
> 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/113126#issuecomment-1650352495):
> @rfcbot fcp merge
>
> Awesome! Going to kick off FCP and we can review and discuss.
## Active FCPs
### "add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053
**Link:** https://github.com/rust-lang/rust/pull/113053
### "Mention style for new syntax in tracking issue template" rust#113586
**Link:** https://github.com/rust-lang/rust/pull/113586
### "Make `unconditional_recursion` warning detect recursive drops" rust#113902
**Link:** https://github.com/rust-lang/rust/pull/113902
## P-critical issues
None.
## Nominated RFCs, PRs and issues discussed this meeting
### "Allow explicit `#[repr(Rust)]`" rust#114201
**Link:** https://github.com/rust-lang/rust/pull/114201
TC: The proposed change here would be insta-stable. @WaffleLapkin [wants](https://github.com/rust-lang/rust/pull/114201#pullrequestreview-1553235377) to know whether T-lang is OK with this.
Josh: Started FCP.
Josh: This seemed like an easy one to do.
scottmcm: I like this being something that you can literally say -- see <https://rust-lang.zulipchat.com/#narrow/search/.22repr.28rust.29.22> for lots for examples of different people already saying this on Zulip.
Josh: I can imagine that in a project where most things are `#[repr(C)]` that you'd want to make the exceptions very clear.
Lokathor: Should we discuss the insta-stable bit?
scottmcm: The proposed FCP includes whether it should be insta-stable.
### "add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053
**Link:** https://github.com/rust-lang/rust/pull/113053
TC: This is entering FCP.
Josh: We started an FCP based on the nomination. We should probably unnominate this.
All: agreed.
### "Lower `Or` pattern without allocating place" rust#111752
**Link:** https://github.com/rust-lang/rust/pull/111752
Un-nominating since it's going through an FCP.
### "Tracking issue for `#![register_tool]`" rust#66079
**Link:** https://github.com/rust-lang/rust/issues/66079
TC: @xFrednet has [summarized](https://github.com/rust-lang/rust/issues/66079#issuecomment-1647519977) what may be blocking this issue:
> From the previous discussion, it sounds like the main concern with stabilizing this feature is the question of how attributes should be handled and what implications this will have for the future.
>
> For external linters, the main concern is the ability to use lint names in lint attributes, like this:
>
> ```rust
> #[allow(marker::super_helpful_lint)]
> fn unknown_linter() {}
> ```
>
> Which currently triggers [E0710](https://doc.rust-lang.org/stable/error_codes/E0710.html). (See [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b3b0ba6cf1b82bf2690962f720977433))
>
> Would it maybe be possible to reduce the error to a lint trigger? That would unblock external linters, while leaving all options open when it comes to attributes and other related tool discussions. It would also be inline with the [`unknown_lints`](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#unknown-lints) lint, which is the way rustc currently handles unknown lints, without a tool prefix.
Josh: The blocker has always been when and how you register a tool. Stabilizing this doesn't *seem* like a problem. But we should probably do this in some principled way rather than switching to a lint.
scottmcm: I'm wondering if there's any other pattern here that would be close. People had done work to list out the CFGs. For lints you want a nice way to suppress it. But for a lint rather than an error, I don't know. Maybe there's something there that's not completely horrible. No specific proposal though.
Josh: We had concerns the last time we looked at it. But most of those concerns were, is this the right answer? But it seems we're not seeing anything wildly better.
scottmcm: Putting it in the code seems better than passing it in a build script or as a command-line argument.
Josh: Maybe the requests we made previously for documentation still apply?
pnkfelix/Josh/scottmcm: An RFC is probably appropriate.
pnkfelix: If the proposal is about experimentation, then yes, it's going to need an RFC.
Lokathor: Does it need an RFC before or after reducing it to a lint trigger?
Josh: It would need consensus in some form to do that.
scottmcm: It would need an FCP since it's a one-way door.
Josh: If you want to do the downgrade thing, that needs an FCP.
pnkfelix: The chances of that going through might be stunted.
scottmcm: Downgrading it is also a stabilization. We'd like an RFC for what the stabilization plan should be.
pnkfelix: I'll make a comment to that effect.
### "Explicit Tail Calls" rfcs#3407
**Link:** https://github.com/rust-lang/rfcs/pull/3407
TC: @WaffleLapkin has been [working](https://github.com/rust-lang/rfcs/pull/3407#issuecomment-1639625362) on an implementation.
Josh: I'm pulling this up for discussion. This seems to be pushing hard for an implementation. But it seems to be sidestepping the issue of "don't make the demo look done" with respect to choosing the syntax.
Josh: The premise is that you can go forward with a second and no objections. But I have objections.
Josh: I can't tell whether scottmcm's suggestion was an augmented or different approach.
scottmcm: Yes, it's a reasonable experiment to do on its own. I'm uncertain about the extent of oversight that lang should have on a compiler experiment. Not sure whether we should block experiments on syntax.
Josh: When we talked about the experiment process, we talked about second and no objections. People ask before doing an experiment to get a preview of what the answer would be. I'm suggesting here that the answer will be "no".
TC: Are you saying you would veto this syntax? In the ticket, it seemed like you wanted further discussion.
Josh: No, I just don't want to contaminate the experiment. So I'm objecting to the syntax for that experiment.
tmandry: Are you advocating an explicit syntax in its place?
Josh: I want something that's an obvious placeholder.
Lokathor: So a macro maybe?
Josh: Yes, some kind of placeholder.
scottmcm: I feel like a macro is not in and of itself enough.
tmandry: The `become` keyword was reserved for this use-case.
tmandry: That makes it seem like a fairly natural choice.
Josh: We now have a mechanism for picking arbitrary keywords and introducing it over an edition.
scottmcm: I'd like to let it land with `become` and then change it to a placeholder or other possibilities if needed. Do we want them to implement all of them and let people try them all?
Josh: I'd like people to try the feature and to ask them what they think it should be called.
tmandry: How is this currently blocked?
Josh: It's blocked because I'm telling them no unless they change something.
scottmcm: We should unnominate the RFC maybe since we're waiting on the experiment.
pnkfelix: [Here](https://github.com/rust-lang/rust/pull/112657) is the PR.
Josh: A [tracking](https://github.com/rust-lang/rust/issues/112788) issue has been opened. Some issues have been merged.
tmandry: Like scottmcm, I'm fine with `become` for the placeholder, but Josh, if you have concerns, it seems you should state those clearly to halt the work.
### "Document soundness of Integer -> Pointer -> Integer conversions in `const` contexts." rust#113510
**Link:** https://github.com/rust-lang/rust/pull/113510
(Discussion about what's always been true and what may need to be documented...)
Josh: Concrete proposal for a next step. Anyone think this doesn't need an FCP?.... Hearing none.
Josh: I'll start an FCP to merge. We may want some changes. Maybe @scottmcm, you could immediately file a concern.
pnkfelix: We could land this hypothetically; it's just a step forward; we could later do what scottmcm is discussing.
scottmcm: I'll add comments to the effect of what we'e discussed. I'm also in favor of starting an FCP.
## Nominated RFCs, PRs and issues NOT discussed this meeting
### "MaybeDangling" rfcs#3336
**Link:** https://github.com/rust-lang/rfcs/pull/3336
TC: There's been considerable recent [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/MaybeDangling) of this over on Zulip.
### "Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503
**Link:** https://github.com/rust-lang/rust/issues/54503
TC: Based on feedback from t-lang, @xFrednet [created](https://github.com/rust-lang/rust/issues/54503#issuecomment-1628471905) a [list of use-cases](https://hackmd.io/@xFrednet/expect-attr-use-cases) and is seeking review from t-lang.
### "dyn Trait comparison should not include the vtable pointer" rust#106447
**Link:** https://github.com/rust-lang/rust/issues/106447
TC: The FCP to close this issue has been completed. However, @Amanieu is still [looking](https://github.com/rust-lang/rust/issues/106447#issuecomment-1566147477) for a way forward. There's been some [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/dyn.20Trait.20pointer.20comparisons) on Zulip about this.
### "Make pointer_structural_match normal and warn" rust#110166
**Link:** https://github.com/rust-lang/rust/pull/110166
TC: This has completed its FCP merge, but it is [waiting](https://github.com/rust-lang/rust/pull/110166#issuecomment-1565346604) on the author for some final changes.
### "let-else does not support `else if`" rust#111910
**Link:** https://github.com/rust-lang/rust/issues/111910
TC: @lcnr wants to do this. It's waiting on a t-lang member to sponsor an experiment.
### "RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods" rust#112194
**Link:** https://github.com/rust-lang/rust/issues/112194
TC: We handled this in the design meeting last week.
### "Report monomorphization time errors in dead code, too" rust#112879
**Link:** https://github.com/rust-lang/rust/pull/112879
TC: This is a blocker for the stabilization of `inline_const`. We discussed recently and decided we were OK with it. @tmandry posted a comment asking about a possible crater run. Nothing has moved here since.
### "Replace old private-in-public diagnostic with type privacy lints" rust#113126
**Link:** https://github.com/rust-lang/rust/pull/113126
### "Support overriding `warnings` level for a specific lint via command line" rust#113307
**Link:** https://github.com/rust-lang/rust/pull/113307
### "Tracking Issue for the Rust specification" rust#113527
**Link:** https://github.com/rust-lang/rust/issues/113527
### "Mention style for new syntax in tracking issue template" rust#113586
**Link:** https://github.com/rust-lang/rust/pull/113586