---
title: Triage meeting 2023-08-15
tags: triage-meeting, t-lang, minutes
date: 2023-08-15
url: https://hackmd.io/ZJiCNtIwTE2V2arUsabJ6g
discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-08-15
---

# T-lang meeting agenda

* Meeting date: 2023-08-15

## Attendance

* Team members: Josh, pnkfelix, scottmcm
* Others: TC, Lokathor

## Meeting roles

* Minutes, driver: TC

## Summary

Summary of the meeting:

- There's been recent [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Should.20lang.20be.20consulted.20on.20I.2FO.20safety.3F) on the accepted "I/O Safety" [RFC 3128](https://github.com/rust-lang/rfcs/issues/3128). The question is whether it intended to have an effect on the *language* rather than just on the standard library. Or alternatively, whether the standard library even *can* make the guarantee in that RFC without certain guarantees from the language. Or whether the standard library doing this has broader ecosystem considerations that may be in the domain of t-lang as it may be seen as requiring all code to use the standard library to soundly access file descriptors. Or whether t-lang may have an opinion on how t-libs uses `unsafe` if that use is to enforce library invariants unrelated to preventing unsafety. The meeting consensus was to ask @*T-libs-api* for a more concrete proposal to help clarify the situation.

- On [dyn upcasting coercion](https://github.com/rust-lang/rust/issues/65991), which moved forward last week into a proposed FCP merge, a concern has been raised due to feedback from @**RalfJ** and @**lcnr** that the proposal may not be clear enough about the intended effect of the change, e.g. with respect to raw pointers. The meeting consensus was to nominate this for @*T-types* to resolve the question of whether the stabilization report addresses the type system changes or whether more work is needed (and if so, what questions specifically should be answered by t-lang).

- In [#114679](https://github.com/rust-lang/rust/pull/114679), @**Michael Goulet (compiler-errors)** argues that because we already allow casting `dyn Trait + Send` to `dyn Trait`, we should allow casting from `dyn Send + Trait` to `dyn Send`, and that this is a good change for consistency and for reuse of the same code paths. The meeting consensus was to nominate this for @*T-types* to write up a stabilization report if immediate stabilization is wanted (or otherwise to add a feature gate).

- In [#114582](https://github.com/rust-lang/rust/issues/114582), @**RalfJ** points out that certain compiler intrinsics don't fit within the memory model of the Rust Abstract Machine. For this one in particular, in the time between doing a non-temporal store and before doing a store fence, things are a bit nuts. But this has a performance benefit as it bypasses the cache, so "fixing" it by eliminating the performance benefit isn't a good option. The meeting consensus was to table this while looking for ways to raise awareness. As @**scottmcm** said, "it wouldn't be the first thing you could do in unsafe that turns out to be sketchy."

- In [#114845](https://github.com/rust-lang/rust/pull/114845), @**scottmcm** raised the issue of documenting that `NonZeroI32` and `Option<NonZeroI32>` are guaranteed to have the same size *and alignment*. As he said, "as far as I know, this is always true already, but it’s not in the text of the `Option` module docs". The meeting consensus was to FCP this with t-lang and @*T-libs-api*.

## Scheduled meetings

- (done) "Extern types V2 RFC" [#211](https://github.com/rust-lang/lang-team/issues/211)

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

## Announcements or custom items

### Should T-lang be consulted on "I/O Safety"?

TC: The discussion is [here](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Should.20lang.20be.20consulted.20on.20I.2FO.20safety.3F).

TC: The question here is about the scope of [RFC 3128](https://github.com/rust-lang/rfcs/issues/3128). Did it intend to have an effect on the *language* or just on the standard library?

TC: There's a related question here about the proper usage of `unsafe`. Should [`FromRawFd::from_raw_fd`](https://doc.rust-lang.org/std/os/fd/trait.FromRawFd.html#tymethod.from_raw_fd) be an `unsafe` function? Is this just about *correctness* or about *safety* (from UB)?

Josh: This is definitely a library item and not a language item. We should state this is definitely not within our scope. But there is a more general concept here about how far our safety goes. The rest of the world still exists. But we shouldn't block I/O safety on it.

Scott: Is there a really clear statement about what we can really rely on for I/O safety?

Josh: Not yet. There are drafts of documentation.

TC: The RFC probably didn't touch on the language. But some of the documentation in that PR might.

Josh: Right. This raises questions about interpretation about what is library-level UB rather than language-level UB.

scottmcm: We need a statement of what the guarantee we're trying to make actually is. This reminds me of the Leakpocalyse. Something that's a library change can affect more than that. If there's an environment rule here, it might end up being lang.

Josh: Right. Part of the issue is that the current proposals on the table would be entirely within the scope of libs. But a broader promise would certainly touch on lang.

Lokathor: I believe RalfJ's concern is that changing what's safe to do with the filesystem has affect on the ecosystem.

Josh: Effectively, is this a guarantee of the stdlib, or is that the only way to do it?

Lokathor: There's a conflict between ecosystem crates and the stdlib; if the stdlib makes any guarantee, then you can only go through the stdlib.

pnkfelix: There hasn't been enough discussion over @scottmcm's comment early in the thread about making POSIX calls unsound. We should talk about that. I was recently doing some `setjmp` work. It's POSIX, but of course, we can't support that at the language level in Rust. So POSIX isn't the final determinant. But either the language must solve the problem or we have to allow C interop.

pnkfelix: In the case of this `close` business... there's a lot to discuss and distinguish.

scottmcm: What I understand from RalfJ's comments there... the close itself doesn't do something that we've defined as UB, but it puts the world state somewhere that can result in safe code triggering UB.

Josh: It's an open question whether it's a soundness question or one of incorrectness. If I open a pipe and write to one end and read from the other, and if someone could close the FD out from under you, you could read something different and behave incorrectly. Whose fault is it?

TC: Another simple case. You open `/proc/self/mem` (but don't write to it) or you `mmap`. Somewhere else does `write(rand(), ..)`. Whose fault is the resulting unsafety?

Josh: The whole concept of pick a random FD you didn't open and write to it causes grief.

Josh: Part of the issue here is that you have a resource that is process global and anyone can manipulate the state, either Rust code or not Rust code. When you see a concrete example, it's easy to see who caused the bug.

TC: Where do we draw the line back to safety?

Josh: In order to have a safety guarantee or a lack thereof, we need a general rule.

scottmcm: We need from libs-api a statement of what is the actual guarantee that libs-api expects this to offer.

Scott: I think we need to figure out "safety" vs "correctness" here, like the examples in <https://github.com/rust-lang/rfcs/pull/3458#discussion_r1263226869> -- the same API can be written in either way.

scottmcm: We need a clear statement to act on.

TC: Would T-lang want to rule on it if t-libs were to use `unsafe` in a way that enforced correctness but not safety against UB? I.e. does T-lang own the concept of "unsafe" in Rust?

scottmcm: (some thoughts)

Josh: Proposed response to the thread:

> We talked about this in today's lang meeting. The *current* proposals on the table don't *seem* like they touch on lang matters rather than libs-api, though it's possible some other alternate/broader proposals might. it would help to see the concrete proposal libs-api ultimately wants to run with.

Lokathor: Let's get a restatement.

all: Agreed.

(Discussion proceeded from here to [#114582](#%E2%80%9CNon-temporal-stores-and-_mm_stream-operations-in-stdarch-break-our-memory-model%E2%80%9D-rust114582).)

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

## P-critical issues

None.

## `S-waiting-on-team`

### "Tracking issue for dyn upcasting coercion" rust#65991

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

TC: The consensus last week was to propose FCP merge. @pnkfelix did that.

TC: This prompted @lcnr to raise general concerns with T-lang's stabilization process. As applied here, the concern is that what is being stabilized is maybe too vague.

> @lcnr: "I have some ideas here, like requiring the stabilization report to again fully describe everything that is stabilized, referencing the implementation. I think starting the FCP without any summary of what is stabilized, or stating "implements RFC X", is bound to cause bigger issues going forward. But these ideas are my own and might not necessarily work out too well in practice."

@crlf0710 posted a stabilization report here:

https://hackmd.io/QggP6SJVTa2jb7DjGq0vrQ

@RalfJung agreed with @lcnr and also said:

> Indeed I was about to mention, this commits us to safe dyn upcasting on raw pointers. In other words, the safety invariant for raw dyn pointers requires a valid vtable, and creating a dangling raw dyn pointer will forever be an unsafe operation. (The validity invariant is undecided still, that would determine whether creating a dangling raw dyn pointer is possible at all or whether a vtable is required at any time. This is tracked at rust-lang/unsafe-code-guidelines#166.)
>
> I think this is a reasonable choice, but it is definitely worth calling out.

@scottmcm raised a concern to ensure this was discussed in triage.

scottmcm: The comment looked concerning, but it was hard to say...

scottmcm: Is this making a t-types rule where we should make sure that's clearly phrased and discuss with t-types what they wanted. I'm not sure.

pnkfelix: Reading over it, I'm wondering, was that a hint that there was an oversight here? I've been thinking about this in terms of references and upcasting of them, but I haven't thought much about the case of raw pointers. I'd be OK with that being unsafe.

pnkfelix: Taking the temperature of the room here.

scottmcm: Would prefer to not punt it. Maybe we could nominate it for t-types?

TC: There was a stabilization report after @lcnr's concern. Maybe t-lang could ask t-types to FCP this.

scottmcm: We could nominate this for t-types?

scottmcm: Ask t-types: "Does this stabilization report reflect the type system changes?"

all: Let's nominate this for t-types.

### "Replace old private-in-public diagnostic with type privacy lints" rust#113126

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

TC: We're waiting on @nikomatsakis to remove a concern. The author has replied to this concern.

### "Allow dropping `dyn` trait object's principal" rust#114679

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

TC: This one is new. @compiler-errors raised this one and said:

> Allows us to cast from dyn Trait + Send to dyn Send, dropping the trait object's principal trait. This is distinct from trait upcasting, since it's trivial even if we were to totally rip out upcasting support -- it uses the same codepath as dropping auto traits, like dyn Trait + Send to dyn Trait, which is currently allowed without feature gates on stable.
>
> This seems like something that would be nice to have, if anything, just for consistency. Nominating for T-lang discussion and FCP for that reason. I don't personally think this needs a feature gate, but that is also I guess up for debate!

(The meeting is reading this...)

scottmcm: This makes we want "you can cast it to dyn nothing".

Lokathor: Once it's a dyn Send, can you still try to make it something on the other side?

scottmcm: Probably not.

Lokathor: If you can't recover the original dyn Send part... what's the point?

pnkfelix: The drop still runs.

scottmcm: I'm not sure it's obvious this is wanted for a specific use-case, but it does make sense.

pnkfelix: Just to clarify, this has nothing to do with Drop?

Lokathor: I believe so.

TC: What do we need to do to get this out of the queue?

scottmcm: It looks like CE wants an FCP here. I agree that's probably what we should do.

pnkfelix: Does it need a feature gate?

Lokathor: If no-one wants the feature gate, then why bother?

pnkfelix: A feature gate lets you know if people want this.

TC: But do we care if people want it? CE seems to be saying this is a good idea regardless.

pnkfelix: But we have to be wary of bugs. But I'm not really sure.

scottmcm: A feature gate would be more code than the actual implementation.

pnkfelix: I don't love that argument. But this isn't necessarily an instance of that.

scottmcm: CE's argument is this is more consistent. The other thing this doesn't have is a stabilization report. We could say something like "we'd be fine for this to go in with a feature gate, but if it's going directly to FCP it should have a stabilization report."

all: Meeting consensus, nominate for t-types.

(Discussion proceeded from here to [#114845](#%E2%80%9CAdd-alignment-to-the-NPO-guarantee%E2%80%9D-rust114845).)

## Nominated RFCs, PRs and issues

### "Non-temporal stores (and _mm_stream operations in stdarch) break our memory model" rust#114582

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

TC: @RalfJ raised this issue:

> I recently discovered this funny little intrinsic with the great comment
>
>> Emits a !nontemporal store according to LLVM (see their docs). Probably will never become stable.
>
> Unfortunately, the comment is wrong: this has become stable, through vendor intrinsics like _mm_stream_ps.
>
> Why is that a problem? Well, turns out non-temporal stores completely break our memory model.
>
> ...

Lokathor: What does t-lang want to do if the vendor extends the abstract machine?

scottmcm: This reminds me of pnkfelix's point about `longjmp`.

Lokathor: It is possible, if you know what's going on, to use this with other intrinsics, and it's fine. But otherwise, it can cause problems.

Lokathor: Maybe just be advised.

Josh: Briefly touching on the scope of this... it does seem like a lot of the conflict here is, what does the Rust AM (abstract machine) allow. There are use-cases where it would be useful to specify weak memory orderings in general. I wonder how much we want to solve this in general by providing AM operations that handle weak memory ordering. E.g. RCU in Rust.

scottmcm: Don't know what to do about it. It's a vendor intrinsic, so people have expectations about what it does. People are going to want to use the intrinsic.

Lokathor: There are performance benefits. The non-temporal stores bypass the cache and allow better throughput. After you do the store, before you do the store fence, the rules are temporarily out of whack. After you do a store fence, things are back to normal.

scottmcm: So maybe we could say that you can do this in an ASM block that restores the rules before it is done?

Lokathor: But you typically do this in a loop...

scottmcm: ...so you're whole loop would have to go in assembly, and that would be horrible.

Josh: People are using non-temporal stores because it's weakly ordered... so if we "fix" this it might as well not exist. People call this for performance. If we kill the performance, then it kills it.

scottmcm: Can we delegate this? If RalfJ says we don't have an opsem for this... it seems maybe fine if we don't know how it works.

Lokathor: I think RalfJ would say it's not fine.

scottmcm: Maybe we put a big warning on it.

TC: These are all unsafe anyway.

Lokathor: But most of the vendor intrinsics don't have to be unsafe. They just were by default.

TC: Can anyone think of an action item?

Lokathor: I think it'd be fine for us to table this, as long as we're all aware of it.

scottmcm: It wouldn't be the first thing you could do in unsafe that turns out to be sketchy.

pnkfelix: Maybe there could be a clippy lint or something to raise awareness of it.

Lokathor: Someone put in a docs PR to tell people what they should do here. That person found on GH that people weren't putting in the fence.

(Discussion proceeded from here to the items [`S-waiting-on-team`](#S-waiting-on-team).)

### "Add alignment to the NPO guarantee" rust#114845

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

TC: @scottmcm nominated this today:

> As far as I know, this is always true already, but it's not in the text of the Option module docs, so I figured I'd bring this up to FCP it.

scotttmcm: https://doc.rust-lang.org/std/option/index.html#representation

scottmcm: Josh, if you think this is good, please FCP that PR.

Josh: Layout, size and alignment are distinct.

Josh: Are we all in agreement that this language needs to be FCPed by t-lang and t-libs-api?

all: Agreed.

(The meeting ended here.)

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

### "Lower `Or` pattern without allocating place" rust#111752

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

TC: This is entering FCP and should be unnominated.

### "Report monomorphization time errors in dead code, too" rust#112879

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

This is entering FCP and should be unnominated.

### "Replace old private-in-public diagnostic with type privacy lints" rust#113126

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

TC: This one is waiting on @nikomatsakis.

### "Support overriding `warnings` level for a specific lint via command line" rust#113307

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

TC: This is in a t-compiler proposed FCP, but @jieyouxu has a [specific question](https://github.com/rust-lang/rust/pull/113307#issuecomment-1628161766) for t-lang.

TC: We [discussed](https://hackmd.io/Hoo205tDQc6vwWAYaYF37g?view#%E2%80%9CSupport-overriding-warnings-level-for-a-specific-lint-via-command-line%E2%80%9D-rust113307) this in the meeting on 2023-07-25 without resolution.

### "Document soundness of Integer -> Pointer -> Integer conversions in `const` contexts." rust#113510

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

TC: @scottmcm on 2023-08-03:

> (Re-nominated to encourage discussion of the exact text on Tuesday.)

### "Tracking Issue for the Rust specification" rust#113527

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

TC: We've created a new [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr) for this work.

TC: A [job description](https://hackmd.io/tAC6D9SOT1ChxIJ2m1VQ2Q) for the editor has been discussed. There seems to be consensus to move forward on the hiring process.

TC: There is [outstanding discussion](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/the.20name.20of.20the.20doc) on the appropriate name of this document.

TC: We [discussed](https://hackmd.io/VY0E31zbTMCRXx-BZRluxA#Rust-specification-progress) various ways of unblocking this work as a separate agenda item.

### "Allow explicit `#[repr(Rust)]`" rust#114201

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

TC: This is entering FCP. @tmandry had nominated this to discuss the name, but has since resolved his concern.

### "Disallow *references* to `static mut` [Edition Idea]" rust#114447

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

On 2023-08-04, @scottmcm proposed for discussion:

> Now that we have `ptr::addr_of_mut!`, the 2024 edition would be a great time to do @RalfJung's idea from [#53639 (comment)](https://github.com/rust-lang/rust/issues/53639#issuecomment-415487264):
>
> **Disallow `&MY_STATIC_MUT` and `&mut MY_STATIC_MUT` entirely.**
>
> `ptr::addr_of_mut!(MY_STATIC_MUT)` could even be safe -- unlike taking a reference which is `unsafe` and often insta-UB -- and helps encourage avoiding races in the accesses, which is more practical than trying to avoid the UB from concurrent _existence_ of references.
>
> (Maybe people will end up just doing `&mut *ptr::addr_of_mut!(MY_STATIC_MUT)` anyway, but we can't force them to drink.)

### "Allow dropping `dyn` trait object's principal" rust#114679

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

TC: This one is new. @compiler-errors raised this one and said:

> Allows us to cast from dyn Trait + Send to dyn Send, dropping the trait object's principal trait. This is distinct from trait upcasting, since it's trivial even if we were to totally rip out upcasting support -- it uses the same codepath as dropping auto traits, like dyn Trait + Send to dyn Trait, which is currently allowed without feature gates on stable.
>
> This seems like something that would be nice to have, if anything, just for consistency. Nominating for T-lang discussion and FCP for that reason. I don't personally think this needs a feature gate, but that is also I guess up for debate!

## 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 one is waiting on a decision on syntax.

### "RFC: Unicode and and escape codes in 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 one *was* waiting on the author, but the author has now updated the RFC based on the feedback.

### "Add `f16` and `f128` float types" rfcs#3453

- **Link:** https://github.com/rust-lang/rfcs/pull/3453
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3453#issuecomment-1665987694):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Amanieu
> * [x] @BurntSushi
> * [ ] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3453#issuecomment-1665987676):
> Since we define `f32` and `f64` to be IEEE `binary32` and `binary64`, it seems entirely reasonable to also include `binary16` and `binary128` as well, working analogously.
>
> Let's see what others think:
> @rfcbot fcp merge
>
> Though I do expect that this will be non-trivial to stabilize, in terms of implementation effort, like how `u128` was easy to RFC but very hard to make *work* broadly.
>
> Compiler folks: Please comment if you think this should be postponed as impractical to implement in the foreseeable future.
>
> (Practically, we might not accept `f128: Display + FromStr` for a while even on nightly, because of size impacts of being able to accurately print/parse such precision, for example.)
>

TC: @scottmcm proposed to merge this 2023-08-04.

### "Tracking issue for dyn upcasting coercion" rust#65991

- **Link:** https://github.com/rust-lang/rust/issues/65991
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/65991#issuecomment-1670127912):
> Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [ ] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * ensure-we-discuss-lcnr's-thoughts-in-triage (https://github.com/rust-lang/rust/issues/65991#issuecomment-1678581352)
>
> 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/65991#issuecomment-1670127881):
> Following up on: https://github.com/rust-lang/rust/issues/65991#issuecomment-1640732308
>
> After a few consecutive weeks discussing of the data presented in https://github.com/rust-lang/rust/issues/112355, T-lang believes this is ready to stabilize.
>
> [2023-08-01 hackmd](https://hackmd.io/eEpxNWhQTauw9LzsrZqBkQ#%E2%80%9CTracking-issue-for-dyn-upcasting-coercion%E2%80%9D-rust65991)
>
> [2023-08-08 hackmd](https://hackmd.io/VY0E31zbTMCRXx-BZRluxA#%E2%80%9CTracking-issue-for-dyn-upcasting-coercion%E2%80%9D-rust65991)
>
> The basic conclusion is that we think the cost of this will be limited. Namely, sufficiently limited that we can, if necessary, invest in an opt-out mechanism *at some future date*; we do not need to block stabilization today on the addition of a hypothetical opt-in mechanism, because we think migrating to an opt-in mechanism will be overly disruptive to Rust developers.
>
> @rfcbot fcp merge
>

### "Stabilise inline_const" rust#104087

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

TC: This one has been blocked on "Report monomorphization time errors in dead code, too" rust#112879.

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

TC: This is waiting on the author.

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

- **Link:** https://github.com/rust-lang/rust/issues/107645
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789843):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * encapsulation-is-too-powerful (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
> * nested-modules-can-always-define-but-nested-functions-cannot (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789814):
> @rfcbot fcp merge
>
> We held a design meeting yesterday where we reviewed [this document](https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2023-05-31-TAIT-stabilization.md) prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.
>
> The document proposed the following resolution to this issue:
>
> - The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
> - Functions and methods must have the hidden type that they intend to constrain within their signature -- within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
> - Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
> - A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
> - The hidden type may be constrained by functions, methods, constants, and statics.
>
> The doc goes into more detail about the justifications and alternatives.
>
> Given all this, I propose to merge and accept this proposal.

TC: This was discussed in a [design meeting](https://hackmd.io/IVFExd28TZWm6iyNIq66PA) on 2023-05-31. Subsequently @tmandry raised concerns. We had a [mini-design meeting](https://hackmd.io/r1oqcjrzTAK5e_T1IOXeXg) on 2023-06-29 regarding those. A [long thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/TAIT.20mini-design.20meeting.202023-06-29) on Zulip followed from that.

TC: TAIT is also separately affected by the capturing of lifetimes discussed in the [design meeting](https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ) on 2023-07-26. That is pending an RFC that I will be submitting (the [PR](https://github.com/rust-lang/rust/pull/114616) for the implementation is ready).

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

TC: This one is waiting on @nikomatsakis, as above.

## Active FCPs
### "Allow cfg-attributes in where clauses" rfcs#3399

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

### "Lower `Or` pattern without allocating place" rust#111752

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

### "Report monomorphization time errors in dead code, too" rust#112879

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

### "Allow explicit `#[repr(Rust)]`" rust#114201

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