---
title: Libs-API Meeting 2025-10-21
tags: ["T-libs-api", "Libs Meetings", "triage-meeting", "minutes"]
date: 2025-10-21
discussion: https://rust-lang.zulipchat.com/#narrow/channel/259402-t-libs.2Fmeetings/topic/Meeting.202025-10-.7B21.2C22.7D/with/546289012
url: https://hackmd.io/-3EwglvOR2W-jXGyPEoUXQ
---

# Libs-API Meeting 2025-10-21

###### tags: `Libs Meetings` `Minutes`

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Josh, The 8472, Chris, Tomas

Meeting notes: Tomas

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

18 rust-lang/rust T-libs-api FCPs

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/146792 *Implement \`TryFrom\<char\>\` for \`usize\`.* - (3 checkboxes left)
- merge rust.tf/85122 *Tracking Issue for inherent unchecked integer methods* - (3 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/146560 *Add the \`cpuid\` target feature* - (5 checkboxes left)
- merge rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16* - (1 checkboxes left)
- merge rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* - (4 checkboxes left)
- merge rust.tf/145656 *Stabilize s390x \`vector\` target feature and \`is\_s390x\_feature\_detected!\` macro* - (3 checkboxes left)
- close rust.tf/136638 *warn on empty precision* - (3 checkboxes left)
- merge rust.tf/145948 *Stabilize 29 RISC\-V target features (\`riscv\_ratified\_v2\`)* - (3 checkboxes left)
- merge rust.tf/75027 *Tracking Issue for slice::array\_windows* - (3 checkboxes left)
- merge rust.tf/146660 *Tracking issue for release notes of #146410: Iterator repeat: no infinite loop for \`last\` and \`count\`* - (0 checkboxes left)
- merge rust.tf/141994 *add Iterator::contains* - (3 checkboxes left)
- merge rust.tf/129333 *Tracking Issue for \`lazy\_get\`* - (3 checkboxes left)
- merge rust.tf/140808 *Implement Default for &Option* - (2 checkboxes left)
- merge rust.tf/63569 * Tracking issue for \`#!\[feature(maybe\_uninit\_slice)\]\`* - (3 checkboxes left)
- merge rust.tf/65816 *Tracking issue for \`vec\_into\_raw\_parts\`* - (3 checkboxes left)
- merge rust.tf/139201 *Tracking Issue for \`Duration::from\_nanos\_u128\`* - (4 checkboxes left)

1 rust-lang/stdarch T-libs-api FCPs

- merge github.com/rust-lang/stdarch/issues/1935 *Make \`cpuid\` safe and update docs* - (5 checkboxes left)

[jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [the8472 (14)](https://rfcbot.rs/fcp/the8472), [traviscross (1)](https://rfcbot.rs/fcp/traviscross), [dtolnay (2)](https://rfcbot.rs/fcp/dtolnay), [nikomatsakis (3)](https://rfcbot.rs/fcp/nikomatsakis), [scottmcm (5)](https://rfcbot.rs/fcp/scottmcm), [BurntSushi (15)](https://rfcbot.rs/fcp/BurntSushi), [joshtriplett (9)](https://rfcbot.rs/fcp/joshtriplett), [Amanieu (4)](https://rfcbot.rs/fcp/Amanieu)

### (nominated) rust.tf/libs506 *In\-place \`String::replace\_first\` and \`String::replace\_last\`*

The 8472: There's a PR open, requesting to prioritise this ACP.

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

Josh: This mentions `replace_first` and `replace_last`. I'm wondering to what extent people may want `replace_all`.

The 8472: Didn't we discuss that last week?

The 8472: There can't be an in-place replacement. If the replacement is long it would..

Josh: It's using `replace_range`. If you allocate a new chunk of memory and replace something in the memory, you'd have to replace in the end.

The 8472: If you do replace_all, you have to do something clever to avoid multiple reallocations.

Josh: I've seen logic that tries to do exactly that and attempts to not repeatedly move the end of the string. So it moves any given piece of the string only once. That seems sensible but it's not something we have logic for.

Josh: Here's a possible proposed `replace_in_place`. That's interesting but as the author mentioned, you still want `replace_first` and `replace_last`.

The 8472: Do we want that or point people to some sort of rope?

Josh: We already have `replace_range` and this is just using match indicies and `replace_range`. These are very reasonable additions.

The 8472: BurntSushi was pinged, but did not reply.

Josh: That was ten months ago.

The 8472: We probably should have `Pattern` for the needle. The proposal has a needle `str`

Josh: The PR takes a `Pattern` for a `from`

The 8472: Then that's about as good as we can do.

Josh: Approve the ACP and r+ the PR?

The 8472: Sounds sensible.

### (nominated) rust.tf/55724 *Tracking issue for alloc\_layout\_extra*

The 8472: We already discussed this. It's in ACP. We can un-nominate it.

### (nominated) rust.tf/79995 *Tracking Issue for maybe\_uninit\_write\_slice*

The 8472: Nominated for FCP.

The 8472: I think we should check the bigger picture. What the other `MaybeUninit<T>` slice methods do.

The 8472: We have a bunch of other methods on slice. So these are in the right place.

https://doc.rust-lang.org/nightly/std/primitive.slice.html#impl-%5BMaybeUninit%3CT%3E%5D

Josh: Naming bikesheds aside these seem fine to me. I'm all for having safe methods for this.

The 8472: We have the `write_filled`, `write_copy_from_slice` and `write_clone_from_slice`

Josh: Ship it.

The 8472: FCP it.

### (nominated) rust.tf/139201 *Tracking Issue for \`Duration::from\_nanos\_u128\`*

Josh: Yes please.

The 8472: BurntSushi already FCPd it, we can unnominate it.

Josh: Checking a box.

### (nominated) rust.tf/139911 *Tracking Issue for \`exact\_div\`*

The 8472: Still nominated from the previous discussion.

Josh: Amanieu mentioned renaming it to put `_exact` at the end and that makes sense in hindsight. Given we have `div_ceil`, `div_floor`, `div_euclid` this makes sense.

The 8472: I don't disagree with the change. We can un-nominate this.

Josh: We can un-nominate it and let the PRs goforward.

### (nominated) rust.tf/141445 *Add \`FromIterator\` impls for \`ascii::Char\`s to \`String\`s*

The 8472: I think Amanieu or someone didn't like the `char` API in general that much.

Josh: I feel that's something that's fine to go ahead and approve on the basis that all of ascii chr is currently unstable and we can review the API in more detail when it's up for stabilization.

The 8472: I guess. That's more work later.

Josh: It is but I don't think this tips the scale in that regard. We can go ahead and approve this.

The 8472: Do we want the one for `Cow` too?

Josh: I'm all for it.

The 8472: We have an equivalent for String.

The 8472: Not opposed for the `Cow` case but it feels closer to filling in the box.

Josh: That may be but I feel anythnig we offer for `String` we want to offer for `Cow<str>`

The 8472: Can we r+ this?

Josh: Yes, especially since this is asking for `ascii::chr` which is unstable.

Chris: Mention it in the tracking issue so we've got all the APIs in one place.

Josh: I'm wondering about adding FromIterator for ascii::char for char too. And we should have one for `Box<str>`.

The 8472: Should we keep the PR open?

Josh: No, we should r+ and leave a comment.

### (nominated) rust.tf/144336 *Tracking Issue for checked bitshifts*

The 8472: Related to the `exact_div` naming. Was discussed, previously, we'll unnominate it for now.

### (nominated) rust.tf/145628 *\[std\]\[BTree\] Fix behavior of \`::append\` to match documentation, \`::insert\`, and \`::extend\`*

The 8472: It's in FCP, Amanieu nominated it last week.

Josh: I guess it was about "please take a look at the crater run". Yeah we drop the nomination, we're done. The only reason to leave this nominated is that it needs r+ once the FCP is over. But we can do that during triage.

### (nominated) rust.tf/146553 *add trait impls to proc\_macro::Ident*

Josh: The thing nominated here was an `add trait impls` PR. There was also an ACP. https://github.com/rust-lang/libs-team/issues/573

Josh: The `PartialEq` implementation for ident is written as `PartialEq<T>` for any T that's `AsRef<str>`. The symbol part seems fine but doing this for all `T: AsRef<str>` is enough of a blanket impl that it would stop people from writing their own `PartialEq` for their own types.

The 8472: They would have to impl never for `AsRef<str>`

Josh: Yes. And they would also ?? memoization check. I get the impression we avoid blanket impl T when we can.

Josh: We have a lot of reflexive impls -- those are all fine. We have blanket impls on `PartialEq` on references and that's fine. We `PartialEq` for any F where F is a `fn` pointer. We have a `PartalEq` for `[U]` for `[T]`.

Josh: We don't have a single blanket impl that's an `impl PartialEq<T>`. This seems like it would be unfortunate.

The 8472: Comment if you want but I think we should leave this for next week.

Josh: Agreed.

### (nominated) rust.tf/147068 `P-lang-drag-1` *Move CoercePointee to core::ops*

The 8472: Amanieu wanted someone else to decide where it goes. Someone needs to come up with a plan where we put things. Right now we have the marker traits module and the ops module.

Josh: I'd still vote for the `ptr` module where the pointee currently is.

The 8472: Tmandry mention CoercePointee, CoerceUnsized etc.

Josh: Fair, they should be in one place. The main thing that came out of the lang meeting was that this is a Libs call and that someone should decide which thing should go to what module.

The 8472: What do we do. Should we have a discussion on the tracking issue, zulip thread, once we have a week with more people attending.

Josh: Last time we talked no one had a strong opinion. I'm looking at the experimental things in `core::ops`. The majority are things for which we have a dedicated operator. The top of the module and summary says "overloadable operators". Out of the list of things that are stable, as far as I can tell the only one that's not an overloaded operator is `RangeBounds`.

Josh: If you look at the unstable ones, it's `FromResidual` which is related to `Try`. Things like `IntoBounds` for ranges, not an op. `DerefPure` which is a marker trait not an op. Half of these are arguably operators and half are arguably not.

Josh: We should have a documentation of "should this be only for things associated with operators" or "should this be more broadly where most traits live".

The 8472: We could also say that operators go to `core::ops` and associated traits could go to a submodule (`core::ops::traits` or `core::ops::markers`).

Josh: I'd rather if there's a good name to have a top module of that name rather than submodules.

The 8472: Should we ask for volunteers about bikeshedding this?

Josh: Yes, ask who in libs-api is interested in the outcome in this. It would also be nice if going in we had a quick run of a tool that runs the `pub` traits of the standard library and where they currently live.

The 8472: Yes, an overview might help us with a general understanding of what our strategy is.

Josh: we can do that in rustdoc: https://doc.rust-lang.org/core/all.html#traits

Josh: That gives a list of every trait in the standard library.

Josh: RangeBounds is actually duplicated in `core::range` for the new range API. That's interesting in that that can be the canonical place for it and `ops` can just be a re-export. Given that I'd be inclided that `ops` is for operators with some historical re-exports. `marker` is for marker traits (and we need to define what a marker trait is) and we should figure out what to do with traits that are neither.

Josh: Interestingly, `core::sync` is where `Atomic` and `Exclusive` live, but we don't put `Send` and `Sync` in there.

The 8472: `Send` is not necessarily for synchronization.

### (waiting on team) rust.tf/136732 *Implement \`Random\` for array*

Tomas: discussed two weeks ago, sent a reply with the next steps:

https://github.com/rust-lang/rust/pull/136732#issuecomment-3378060391

Tomas: Remove `waiting-on-libs-api`?

removed label since josh replied

### (waiting on team) rust.tf/145504 *Add some conversion trait impls*

Tomas: Author responded to the request, removed the two impls we asked them to drop. Ready for the libs-api team to take another look?

The 8472: Needs FCP

The 8472: Last week we said to remove the first two and the rest is okay.

Josh: They marked those two as unstable in the top comment. They removed the impls, the comment should just be updated. I've updated it.

Josh: This seems fine, shall we FCP it?

### (waiting on team) rust.tf/146009 *Implement \`Receiver\` for \`Exclusive\`*

The 8472: Did we come to a conclusion?

Josh: We came to a conclusion that it doesn't cause any behaviour change. It's an unstable impl on unstable trait on an unstable type. It's fine if we add it, it's fine if we don't.

Josh: We don't want to stabilize this unless we want to implement `DerefMut`. It only exists if we want to implement that. I'm not sure we actually want to make that change. It seems very invasive and very strange for a type that's `DerefMut` but not `Deref`. When will we have another type like that.

Josh: I think we should not add this. Can you name one other type that will ever have DerefMut and not Deref? It seems like a specific use for this specific type.

The 8472: The `&mut` for `!Sync` type isn't `Send`, right?

The 8472: There's an explicit `Send` impl for ?? but it isn't implemented for `&mut`. If the documentation is correct, it should be always Send.

Josh: It says `&mut T` is `Send` if and only if `T` is `Send`; it doesn't have to be `Sync`. And same for `Sync`, `&mut T` is `Sync` if `T` is `Sync`.

The 8472: If we're not going to add this DerefMut and the Receiver only exists to keep that possibility open, I don't think it's worth adding it. I agree.

Josh: More to the point, I don't think there's value in separating the two. This can be trivially added in the future. So if we hypothetically implemented `DerefMut` in the future, we could add the `Receiver` then.

The 8472: But with `Receive` you could still use the arbitrary self types feature, right?

Josh: You could use it if we stabilized it. So yes, you could potentially write something that uses exclusive for this. But it seems the person adding this said they want it to use `DerefMut` in the future. If someone had the use case for that, then we can talk about it then.

Josh: I don't think we should make the type less usable to allow for a future `DerefMut`. Because I don't think we should add the future `DerefMut`.

The 8472: Looking at the Exclusive tracking issue.

The 8472: There's Amanieu's objection regarding the get_mut method: https://github.com/rust-lang/rust/issues/98407#issuecomment-3378398343.

The 8472: Should we FCP the Exclusive type itself?

Josh: Has it actually been there that long?

The 8472: We added it in June.

Josh: Ok, seems fine.

The 8472: There's a stabilisation report from August. People are using handrolled options of it. The only question is the `AsMut` and that can be implemented later.

The 8472: Yeah, I guess we can FCP it. I'll write a comment.

### (waiting on team) rust.tf/147400 *TryFrom\<integer\> for bool*

Josh: This one seems somewhat straightforward to me. We rejected this in 2018 on the basis that it is ambiguous. The minor reason is convention differences: most of the time people want 0: false, 1: true but it's unclear what people want for the rest. And then there's the UNIX convention where 0 means success. And someone can misinterpret the value here.

Josh: The only argument I can see for this is having to write the "if 0 ... if 1 ... otherwise error" code.

The 8472: Our `TryFrom` are never modifying the value. If it maps, it should be round-trippable.

Josh: The definition of From and TryFrom mention that the conversion is obvious: the only reasonable conversion for each type.

The 8472: We have the `as` cast that interprets 0 false and 1 to true.

Josh: And we also have a `From<bool>`. The question is if we want to go the other direction.

The 8472: But if we can enable round trip, we should. We have this for integers, `char`.

Josh: And if you think of `bool` as an enum, this is similar to `TryFrom` to various enums.

The 8472: Even alignment can be from a `NonZero<usize>`

Josh: Alright, no objections. This will need an FCP to overrule the previous decline from 7 years ago. We should have the team explicitly show changing our minds.

The 8472 to reply and start and fcp

### (new change proposal) rust.tf/libs680 *`{str|slice}::strip_affixes`*

The 8472: I don't like the `strip` variant at the first glance. It returns an `Option` and it's unclear what it means: do both ends match or only one end?

Josh: Checking the rarity of the word:

/usr/share/dict/scowl/english-words.20:prefix
/usr/share/dict/scowl/english-words.20:suffix
/usr/share/dict/scowl/english-words.35:affix

Josh: if you search for "affix" in a code search, every result is the verb. As in "I want to affix this to some other data structure".

Josh: Ignoring the bikeshed for the moment, they're trying to solve the problem of wanting to strip the prefix and the suffix.

The 8472: I was seeing it in computer games e.g. Diablo 2. The prefix and suffix were called affix together.

Josh: In CS specifically, "circumfix" might be reasonably more accurate here.

Josh: Strip affixes could also be interpreted as stripping *either* instead of *both*. Strip "circumfix" sounds like it will strip both.

The 8472: Though that sounds awfully close to "parsing HTML with regexes".

Josh: Looking at the examples providing, those seem to be valid use cases. I think I buy this. I think it's a slight readability improvement.

The 8472: But it also seems kind of niche.

Josh: It's absolutely niche.

The 8472: If you're parsing complex data then maybe you should use an actual parser.

Josh: We had the exact argument when strip_prefix and strip_suffix were introduced. I don't disagree with the point that when you're doing anything nontrivial you should pull in winnow something. But for the simple cases you don't need that. The Cargo example linked should not be replaced by a parser library or a regex.

The 8472: Is that a fast path?

Josh: It's not a fast path, it's a check. It distinguishes between two separate cases:

`target.'cfg(windows)'.build-dependencies` vs.`x86_64-pc-windows-msvc`

The 8472: I think this is still too niche.

Josh: I think the fact that we have three different examples across three different Rust codebases suggests it's not that rare.

The 8472: I want to see clear signs of usage before we stabilize.

Josh: That sounds like let's approve the ACP and evaluate the usage before stabilization.

The 8472: Ok.

Josh: Are you fine with the name `circumfix`

The 8472: I think it's clearer than `affix` even though the name is more obscure.

Josh: I think we should decline the `trim_` variant. We already have `trim` which does that for the more specific case. You have to call `trim_matches` if you want all prefixes and suffixes you specify. But you can also just need to do `.trim_prefix(...).trim_suffix(...)`. For `strip_` it's more awkward because you have to do the `.and_then` or two `let`s.

### (new change proposal) rust.tf/libs679 *ACP: Freezable Mutex Guards*

The 8472: I looked at it last week. I thougth they wanted an `Arc<Mutex>` but they say that's not what they want.

Josh: The talk about locking and unlocking is also not just about performance, but it could make the code less correct.

Josh: FreezeGuard is an unlock call lock. What they want is the ability to unlock a mutex temporarily to call a function given you have a MutexGuard.

The 8472: But given the MutexGuard, you could Arc lock it, do something and then lock it again.

Josh: In this case this feels like it's just a condition variable?

The 8472: They brought that up. The top-level comment was updated so the example should hopefully be fixed already.

Josh: One of the complaints they had here was they wanted the ability to do this using a mutable reference. And it doesn't seem like the problem of "call an arbitrary function" is as important. I'm wondering if we could just add a function to `condvar` that does a wait MutRef. But then I'm wondering whether that would break scopes and etc.

Josh: It seems like you could have a `wait(&mut MutexGuard)` and returns a mutable unit. That seems like that would solve their problem if what they want is a condvar.

The 8472: If you pass it to the method, the other method could deref it and mutate the data. ... What can you assume about the mutex guard?

The 8472: MutexGuard is not Send. In the meantime the value can't be accessed by different threads while it's held.

Josh: But you can already unlock the MutexGuard by passing it in value.

The 8472: But if you unlock it, another thread can lock it and mutate the value.

Josh: But that's exactly what condvar does.

The 8472: But you can't do that when you pass a `&mut` to the function.

Josh: We should add this as unstable, draw attention to it and see if it breaks any assumptions.

The 8472: We have the `!Send` impl for the MutexGuard. So the code can currently assume that if it holds the MutexGuard, you can assume no other thread will touch this value in the meantime even if you hand out mutable references to it.

The 8472: You could put teh `&mut` reference into a scoped thread right. That would work. So maybe this isn't as solid an assumption.

The 8472: So the alternative proposal is to have a special method on condvar?

Josh: Yeah, have a wait method that takes a `&mut ScopeGuard` rather than an owned `ScopedGuard`.

The 8472: That makes sense.

Josh: With Tokio's Mutex, the MutexGuard has a method to get a reference to the Mutex.

The 8472: Maybe.

Josh: I wrote a comment.

The 8472: Sounds good.

### (new change proposal) rust.tf/libs677 *ACP: \`std::fs::read\_dir\_all\`*

The 8472: This is a simplified walkdir.

Josh: I though this was `read_dir.collect()`.

Josh: The fact that it's a recursive read_dir is isterenting. I want this. I think we should do this. I would add a big chunk of walkdir to the standard library. But I think that a portion can't be added easily in isolation.

The 8472: There are several crates for filesystem traversal and I've used all of them in different usecases.

Josh: There's walkdir, ignore (walkdir plus filtering) and there's jwalk which is walkdir in parallel. And there's also async-walkdir.

Josh: But that one will be useful if we added get_dense into iouring.

The 8472: Same.

Josh: I genuinely think it would be fun to have a synchronous target that's x86-64-unknown-linux-uring where the entire implementation is supposed to run on iouring.

The 8472: Interesting. I don't think it would speed things up that much.

Josh: The rationale is it could use thread pool to do this for you. You would have one uring shared across all the threads inthe process.

The 8472: You're talking about just synchronous std api, right?

Josh: Part of the rationalle is you wouldn't have to make actual syscalls, you could just do polling.

The 8472: Doesn't that require root?

Josh: I think some of it may be available to non-root? 5.11 and newer allows you use non-root if you have CAP_SYS_NICE and as of 5.13 you can do SQ_POLL with no privileges.

The 8472: And it's not polling all the time, it stops polling at some point, right? And you'll need to re-arm it.

Josh: There is a thread_idle_ms that you can set. But you can in theory set that for a large number of milliseconds.

The 8472: I found myself wanting the multithreading, filtering, skipping entire subtrees.

Josh: I've used a half-a-dozen features of walkdir and a trivial implementation walkdir is not sufficient

The 8472: In the std we have been conservative about every time you call metadata you get fresh metadata. And a crate has more flexibility to be efficient.

Josh: That's true. There's also a limit in how many file descriptors you can have at one time. Walkdir has logic where it can close things and reopen them later.

The 8472: And it also has loop detection.

Josh: You need that only if follow_links is true.

The 8472: That's complicated that I'm sceptical we'll want this in the standard library.

Josh: I still want it, but a single ACP isn't enough and a single function with no parameters is enough.

Josh: Close the ACP and say that the thing we'd consider is a more fully-featured walkdir.

The 8472: I think this is above our complexity threshold that we'll get done any time soon.

Josh: I'd prioritize this below the rewrite of `Path`.

The 8472: For practical reasons, we should not encourage someone to run off and do a lot of design work.

Josh: I agree. I'd phrase it as: we don't want to do the simple case, this would require a lot more design work and we would not recommend doing this without talking to us first.

The 8472: Agreed.

The 8472: And I think the ecosystem crates do the job just fine. They're not abandoned.

Josh: The crates in the ecosystem are just fine. This is more of a: "if something has a hundreds of millions of the ecosystem we should consider whether it's stable enough". I'm trying to push Random in. This seems easier. I want to push bitflags.

The 8472: random I agree, it's complex. I'm not sure we should be doing this for bitflags.

Josh: For bitflags I'm not sure if that's a library or language feature.

### (new change proposal) rust.tf/libs676 *\`only\` on iterators*

### (new change proposal) rust.tf/libs674 *Vec::recycle*

### (new change proposal) rust.tf/libs661 *ACP: More float constants*

### (new change proposal) rust.tf/libs660 *ACP: std::rc::RcUninit for deferred initialization and await\-safe cyclic construction*

### (new change proposal) rust.tf/libs659 *Generalize ExactSizeIterator to QuantifiedIterator*

### (new change proposal) rust.tf/libs656 *implement Default for more iterators*

### (new change proposal) rust.tf/libs653 *ACP: Add 1 type parameter to \`RangeBounds\<Start, End = Start\>\` and all existing range types*

### (stalled change proposal) rust.tf/libs347 *Context reactor hook*

### (stalled change proposal) rust.tf/libs296 *ACP: Designing an alternative \`FromStr\`*

### (stalled change proposal) rust.tf/libs457 *APC: split\_pattern on slices*

### (stalled change proposal) rust.tf/libs371 *ACP: primitive numeric traits*

### (stalled change proposal) rust.tf/libs504 *Implement Read and Write for Arc\<T\> for types where &T implements Read and Write, \*and\* it is safe to do so.*

### (stalled change proposal) rust.tf/libs304 *ACP: Avoid the common mistake of \`for x in 0u8..\`*

### (stalled change proposal) rust.tf/libs395 *\`impl core::str::Pattern for \[&str; N\]\`*

### (stalled change proposal) rust.tf/libs348 *std::os::unix::env::{argc, argv}*

### (stalled change proposal) rust.tf/libs111 *Restructure ptr\_metadata to minimal support*

### (stalled change proposal) rust.tf/libs336 *Add \`or\_try\_\*\` variants for HashMap and BTreeMap Entry APIs*

_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_