Libs-API Meeting 2025-10-14

--- title: Libs-API Meeting 2025-10-14 tags: ["T-libs-api", "Libs Meetings", "triage-meeting", "minutes"] date: 2025-10-14 discussion: https://rust-lang.zulipchat.com/#narrow/channel/259402-t-libs.2Fmeetings/topic/Meeting.202025-10-14/with/544780899 url: https://hackmd.io/Uufd0WszSi-_l-xbjAPuZA --- # Libs-API Meeting 2025-10-14 ###### tags: `Libs Meetings` `Minutes` **Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr **Attendees**: Amanieu, Josh, The 8472, Chris Denton, TC ## Agenda - Triage - Anything else? ## Triage ### FCPs 28 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\`.* - (4 checkboxes left) - merge rust.tf/85122 *Tracking Issue for inherent unchecked integer methods* - (4 checkboxes left) - merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left) - merge rust.tf/146560 *Add the \`cpuid\` target feature* - (6 checkboxes left) - merge rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16* - (2 checkboxes left) - merge rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* - (5 checkboxes left) - merge rust.tf/136306 *Tracking Issue for NEON fp16 intrinsics* - (3 checkboxes left) - merge rust.tf/145656 *Stabilize s390x \`vector\` target feature and \`is\_s390x\_feature\_detected!\` macro* - (4 checkboxes left) - close rust.tf/136638 *warn on empty precision* - (3 checkboxes left) - merge rust.tf/145628 *\[std\]\[BTree\] Fix behavior of \`::append\` to match documentation, \`::insert\`, and \`::extend\`* - (3 checkboxes left) - merge rust.tf/145948 *Stabilize 29 RISC\-V target features (\`riscv\_ratified\_v2\`)* - (4 checkboxes left) - merge rust.tf/135889 *Tracking Issue for \`VecDeque::pop\_front\_if\` & \`VecDeque::pop\_back\_if\`* - (3 checkboxes left) - merge rust.tf/126769 *Tracking Issue for \`substr\_range\` and related methods* - (4 checkboxes left) - merge rust.tf/144090 *Make \`IoSlice\` and \`IoSliceMut\` methods unstably const* - (3 checkboxes left) - merge rust.tf/146705 *Tracking Issue for \`fmt\_from\_fn\`* - (3 checkboxes left) - merge rust.tf/146882 *fully deprecate the legacy integral modules* - (3 checkboxes left) - merge rust.tf/145665 *Don't require \`T: RefUnwindSafe\` for \`vec::IntoIter\<T\>: UnwindSafe\`* - (3 checkboxes left) - merge rust.tf/117729 *Tracking Issue for \`debug\_closure\_helpers\`* - (3 checkboxes left) - merge rust.tf/75027 *Tracking Issue for slice::array\_windows* - (3 checkboxes left) - merge rust.tf/146939 *Tracking Issue (take 2) for \`more\_float\_constants\`* - (3 checkboxes left) - merge rust.tf/146660 *Tracking issue for release notes of #146410: Iterator repeat: no infinite loop for \`last\` and \`count\`* - (1 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/146561 *Change \`Location\<'\_\>\` lifetime to \`'static\` in \`Panic\[Hook\]Info\`* - (3 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) [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [scottmcm (4)](https://rfcbot.rs/fcp/scottmcm), [the8472 (20)](https://rfcbot.rs/fcp/the8472), [traviscross (1)](https://rfcbot.rs/fcp/traviscross), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis), [joshtriplett (17)](https://rfcbot.rs/fcp/joshtriplett), [BurntSushi (21)](https://rfcbot.rs/fcp/BurntSushi), [m-ou-se (15)](https://rfcbot.rs/fcp/m-ou-se), [Amanieu (3)](https://rfcbot.rs/fcp/Amanieu) ### (nominated) rust.tf/55724 *Tracking issue for alloc\_layout\_extra* Decision: - Stabilize `repeat`, `repeat_packed`, `extend_packed` - Stabilize `dangling` but rename to `dangling_ptr` - Defer `padding_needed_for` until `Alignment` is stable ### (nominated) rust.tf/139911 *Tracking Issue for \`exact\_div\`* ### (nominated) rust.tf/144336 *Tracking Issue for checked bitshifts* ### (nominated) rust.tf/147068 `P-lang-drag-1` *Move CoercePointee to core::ops* ### (nominated) rust.tf/147658 `nightly-2025-10-12` adds a breaking change to `std::io::Error::description()` ### (new change proposal) rust.tf/libs677 *ACP: \`std::fs::read\_dir\_all\`* ### (new change proposal) rust.tf/libs676 *\`only\` on iterators* Amanieu: We have ACP 229 which we rejected and then marked as accepted. https://github.com/rust-lang/libs-team/issues/229 Amanieu: The ACP is accepted in htat we want conversion APIs but more discussion was needed. The 8472: There was a related issue on the Rust repository, there was a discussion that fizzled out about the next_chunk on where to support it. That's where it got stuck. Amanieu: And really what we want is try_collect. The 8472: try_collect takes a `&mut self`. Amanieu: When a failure happens, the iterator is still valid. Not a fan of iterators taking `&mut self`. Amanieu: I don't think that's the right thing here. I'm inclined to have some API. I don't know what shape. It should be: "give me an array from this iterator and give me None if the iterator length isn't exactly the length of the array" The 8472: Should it be `None` or should we do somethiing better? Amanieu: The most common case is: I know exactly how many items there are, give me an array. The 8472: And if your array has exactly one item, you can destructure it to that item. Amanieu: exactly. The 8472: I guess we can do that. `to_array`? Amanieu: Does `itertools` have this? Amanieu: `collect_array`. That's what itertools have. Are we down for that? The 8472: Could we be shorter? But in principle that's fine? Amanieu: `collect_array` feels more correct. It matches the `collect` people already know. The 8472: But `collect` is into a generic iterator sync. This is more specific. Amanieu: It is, but we can't use collect or try_collect. What do people think? The 8472: Sure, let's ask. Amanieu: I will reply. ### (new change proposal) rust.tf/libs675 *Add \`\[u8\]::split\_ascii\_whitespace\`* The 8472: Is it proposing to have something that's only implemented on string types to also be on `[u8]` slices? Amanieu: This seems fine. Seems like it was an oversight. The 8472: We don't have anything on ByteStr. This would be the first method. The 8472: They say n-split-whitespace but that's not ascii_whitespace. That doesn't make sense. Amanieu: The proposal is just to add `split_ascii_whitespace`. The 8472: ok. Amanieu: I'll reply. ### (new change proposal) rust.tf/libs674 *Vec::recycle* Tthe 8472: Reuse an allocation of an empty vector. There's a lot of discussion on which vectors to apply this to. Chris: The discussion settled on what to do with lifetimes. Amanieu: Is this about just the storage? The 8472: Storage. It would apply to an empty vec or clear it. Amanieu: This feels like into_raw_vec and from_raw_vec. The 8472: There was an RFC, we rejected it. Chris: The idea itself was wanted, it was some limitation at the time. Amanieu: *looks at the RFC* it was not implementable at the time. Amanieu: discussed in the libs meeting: https://github.com/rust-lang/rfcs/pull/2802#issuecomment-867110260 The 8472: I think this ACP solves this by being less generic to what the RFC proposes by only changing the lifetime. But we don't have a way to implement the bounds that it's the safe time other than the lifetimes. Amanieu: There is a SafeTransmute trait that was unstable. Chris: So long as it's internal we can use it. Amanieu: It would be in the `where` bounds. The 8472: So the ACP still lack the mechanism to do the compile-time checking. The 8472: I think we didn't have const asserts back when the RFC was proposed. Post-mono is an option we could take but people are not happy about those. Amanieu: `try_recycle` seems nice? The 8472: That goes back to the RFC argument that it might unexpectedly fail on some platform if the layout doesn't match. Assuming you're talking about having different input and output types. So if someone just slaps an expect on it, it compiles on 64 platforms and blow up on 32. Chris: And Rust structs can change between compilers. The 8472: And randomize layout can too. Amanieu: What's the broader context we need the recycle? https://databento.com/blog/why-we-didnt-rewrite-our-feed-handler-in-rust The 8472: They had a loop with a `Vec<&[u8]>`. Amanieu: Recycle won't help you. The 8472: You can recycle into the body. Amanieu: How? The 8472: You stash it into a Vec with a static lifetime. I've written something similar. Amanieu: So have I. Amanieu: How does this work in C++ even? Do they just use raw pointers? Chris: yeah, they don't have lifetimes, it just works. The 8472: I think there's not much of an argument we don't want this. We said before this is useful. Just having this foolproof in the standard library is .. Amanieu: It still feels like the specific use case is into storage / from storage. But that doesn't help with the lifetime issue. The 8472: Yeah we have to store the alignment, because the allocater is alignment sensitive so we need to keep track of that. And as soon as we allow a different input and output type we run into platform dependence. Amanieu: Trying to think if recycle is the right solution for this issue. The 8472: I don't see how the different solution would avoid the problems. Amanieu: Checking that the layouts match? The 8472: yeah. The 8472: The alternative is to do this opportunistically, throw away the ?? type but then you get a performance error. Which is what the iterator approach does. Amanieu: I think the runtime error is the worst of all worlds. Amanieu: try_recycle which returns an Option that you can do unwrap or vec_new. The 8472: Then we have the same problem with platform dependence. Amanieu: That's always going to be an issue. The 8472: Not with the opportunistic one: it would just return an empty vec. There's no error case. Amanieu: I'm inclined to have the error case to let people choose. The 8472: But does the portability argument not apply anymore? You code it on one machine, it works, it blows up at runtime on another machine? The 8472: Whenever you do `unwrap` your code now depends on the layout. If we're just returning an empty vec we're not tricking users into `unwrap`. relevant zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Vec.3A.3Areuse/with/544015903 Amanieu: The proper solution is `safe_transmute`, but that's somewhat dead at the moment. I've not seen any movement there. The 8472: Is it on the project goal list? Amanieu: Not anymore. Ther's a safe transmute group started in 2019. That seems dead too. The 8472: Our options are to reject/postpone it for the same reason the RFC was. Or asking for some sort of compiler/lang magic for the lifetime difference (i.e. to get a way to detect different types are the same except for their lifetimes). Or `maybe_recycle`? Chris: The ACP is quite new. Could we summarize this and ask them to come up with other options? The 8472: I don't see many more options. Chris: Maybe someone cames along and says they're working on safe_transmute The 8472: We can of course give up and deliver a worse API than we initially wanted. Amanieu: We have the [`TransmuteFrom`](https://doc.rust-lang.org/nightly/std/mem/trait.TransmuteFrom.html) trait. It's automatically implemented for all types. Amanieu: No activity from August last year. The 8472: It's unstable. There must be some limitations. Amanieu: There are some unresolved questions. The 8472: And it's an MCP, it's not even RFCd. It's just an experimental feature. We could have an unstable API based on that but nothing stable. Amanieu: That's my preferred outcome. Put a trait bound that says "this type must be the same size and alignment as this type". The 8472: Are you proposing to have an unstable method that's blocked on safe_transmute? Amanieu: Yeah. That's going to take a while unfortunately. I'd hate to have this method have a poor API once safe transmute becomes stable. If it ever does. Amanieu: I'll write up a comment proposing using the `TransmuteFrom` trait and ping the `safe_transmute` maintainer to see if there's any progress. ### (new change proposal) rust.tf/libs673 *Add \`VecDeque::extract\_if\`* Amanieu: This is an easy accept I think. The 8472: Sure. If there are no implementation issues, yeah. The 8472: On `Vec` we take a Range. They're proposing that here too. ### (new change proposal) rust.tf/libs670 *Allow arbitrary initializers in \`LazyCell\` and \`LazyLock\`* Amanieu: We've discussed this last week. The 8472: Did we skipped that? The 8472: I think we first wanted to say: "can that just be Once?" But then we looked closely and they wanted to smuggle something in the uninitialized version. Amanieu: Rather than trying to use `LazyCell`, write your own enum. `LazyLock` is more tricky because it involves atomic stuff. Amanieu: The motivating usecase is mostly in `LazyCell`. The 8472: The `LazyLock` is generic wwith a `T` and `F` currently. Couldn't we add another generic argument `U` and T and the F being a function that takes an argument to do the transformation? Amanieu: Currently `F` takes no argument, how would that work? The 8472: It would have to be a differnt impl in a different block. Are they allowed to have the same name if they're of distinct types? Amanieu: I don't think so. I think name resolution just fails in this case. Because it runs before any trait bounds are checked. Although we do have length resolution. Amanieu: I think the API is completely wrong. The 8472: I think overloading works at least with concrete types. I don't know if it works with non-overlapping generics. The 8472: (checks)So we would need different names. Amanieu: Notably into_inner assumes the LazyCell. I strongly feel into_inner should consume the cell and execute the function. The 8472: `Deref` execute ?? and we can't implement overlapping Deref. That would be the issue. We would have to somehow make a non-overlapping case or use specialization. Too complicated. Amanieu: It's something that wouldn't even deref. And that's the whole point of this. I'm inclined to close just on the deref function. The 8472: Why is the LazyLock more generic than the constructor? It has an arbitrary F in the struct declaration. Amanieu: That's quite normal, we often put the constraint on fn/impl Amanieu: I'm inclined to reject this, the usage pattern doesn't fit the type. The 8472: OnceLock? Amanieu: For LazyLock it's not an easy way. But that's not the motivating use case -- they mainly mentioned the LazyCell and they're better off writing their own. The 8472: programmerjake agrees making this change to LazyLock is a good idea. Amanieu: Adding it to LazyCell is better than adding it to OnceCell but it's still a bad idea. The 8472: Was this originally proposed for OnceCell? No... So I don't know what he's referring to. ### (new change proposal) rust.tf/libs667 *Adding \`is\_bit\_set\` methods for (u)int types* Amanieu: I hate the method name `is_bit_one` Chris: Yeah, that's a terrible name. Amanieu: How would you handle out of bounds bits? I'll look at the API of bitflags. There at least the bits are somewhat type safe. Amanieu: the interesting parts are `bit_set`, `bit_toggle`, `bit_test`. The 8472: I like the `get_bit`. Chris: Except we use `get` in the standard library. The 8472: `bit` and `set_bit`. Amanieu: Oh yea someone said get_bit/set_bit with unchecked versions. Amanieu: I'm down for `get_bit`/`set_bit`. The 8472: What about the "get"? Amanieu: I guess we could eliminate it. The 8472: It fits into our usual naming scheme. We don't have `get_` accessors. We just name the thing. Amanieu: Sure. Second opinion from anyone? TC: It makes sense to me to just call it `bit`. Amanieu: Are you happy with the existence of these methods in general? Chris: It's useful when chaining if statements when you have multiple `&&`. Amanieu: I think we use `bit` for some other names. Let me check. `bit_width`? TC: I've reached for these things before. Other languages have them. Makes sense to have. Amanieu: We have `first_bit`. But not any other methods. Amanieu: I'm okay with this. We accept the names `bit`/`set_bit`. TC: Do we do the unchecked ones too? The 8472: At that point you can just have the unchecked shifts. Amanieu: This should handle the overflow checks so we don't get penalized in the release version. But then we need `checked` versions. Amanieu: I can see diferentt ways of handling overflow: UB, panic, return an option, wrap, wrap-or-panic depending on whether we're in debug builds. Chris: We can return zeros. Amanieu: Is that true for non-negative signed numbers? The 8472: I don't think we have checked rotate? Amanieu: Rotate is implicitly wrapping so if you overflow it doesn't matter. It just wraps around. TC: I'd probably expect bit and set_bit to panic on out of bounds conditions. But I'd also expect the unchecked versions to be there. Amanieu: Would you also panic in release builds? TC: I'd have to look at the other operations. Amanieu: Shifts depend on the overflow checks. They inherit them. The 8472: We could tell users "if you want more explicit control, then write the bit bashing method" Amanieu: What do we want the easy thing to be. I think we should follow the same API as shift which is overflow checks and release mode is wrapping. Amanieu: I'd even get rid of the unchecked ones. The 8472: Another option is getting rid of the const time? AManieu: peopel absolutely need runtime. Bitsets are a thing. Amanieu: Thoughts on the unchecked operations? I'd get rid of them. Amanieu: On x64, ARM64 and risc there's no runtime penalty for wrapping. The 8472: If you're writing unsafe code you already know the bit operations manually. This is convenient, not essential. The 8472: And the platform can eliminate the masking if the instructinos have it alerady. TC: Makes sense. ### (new change proposal) rust.tf/libs665 *ACP: Intuitive alternative for \`.min()\` and \`.max()\`* The 8472: If you work with a usize and your minimum is zero, you just set the maximum to one half. Having an explicit method is nice. The only complaint I see is two methods doing the same and being oppositly name. Amanieu: That's my biggest concern. I can't unfortunately find better names. The 8472: The min and max is what everyone stumbling over. Amanieu: no, they're too common. So these would be new methods on the Ord trait. The 8472: And the proposal also says `Ord + Float`. So, approve? Amanieu: Sure. It's going to be on nightly anyways. I'm happy to approve, we'll see if people complain. ### (new change proposal) rust.tf/libs664 *Host tuple available without build.rs* Amanieu: This proposes adding the full tuple here: https://doc.rust-lang.org/nightly/std/env/consts/index.html Chris: This feels to me as something that would be fixed by Cargo. I think lang said they don't like people matching the full target. Amanieu: It's essentially useful for build tools to know what the running target is and pass that back to cargo. Chris: Which is why I think it's on Cargo to set the environment variable for them. Amanieu: Oh yeah, you can just take env, right? Amanieu: I do think this should probably a Cargo environment variable rather than something in the standard library. The tuples feel like a cargo/rustc thing. The 8472: It's an ecosystem thing. We're coordinating with differenrt tools. Amanieu: Right, we can build something without cargo. The 8472: The target tuples are also used by C compilers etc. Amanieu: Our target tuples are not at all compatible with the C ones. Chris: cc.rs struggles with this a lot. Amanieu: Do we prefer for this to be done in Cargo? TC: There's a lang question here about the `cfg_value!` macro. With that, it's not clear we'd still need this. The 8472: That's mentioned in the alternative. TC: That seems like a plausible alternative to me. We have lots of reasons for wanting that. ### (new change proposal) rust.tf/libs662 *ACP: Add unchecked arithmetic methods for integer simd* Amanieu: I marked that as accepted, set the label. ### (stalled change proposal) rust.tf/libs459 *ACP: Expose rustc\_lexer::unescape Functionality in the proc\_macro Crate for Standardized Literal Parsing* Amanieu: This has already been implemented. I'm going to accept the ACP because of that. ### (stalled change proposal) rust.tf/libs484 *Support \`vec!\[const { ... }; n\]\` syntax for creating a \`Vec\` of non\-\`Clone\` values* Amanieu: The issue is that Vec clones the first argument the first time. Here we have an enum that's not Clone, but you can const-construct it. The 8472: Like in arrays. Amanieu: Maybe the answer is "don't do this from the vec macro but have a from_fn" TC: I remember it being difficult to be consistent across the board. See the table in this comment: https://github.com/rust-lang/libs-team/issues/484#issuecomment-2492864843 Amanieu: I don't think there's a way to implement this. The 8472: We could write a loop and have the const fn in the loop. Amanieu: How do we differentiate cloning and const instantiation? From the decision last time we decided not to match on const. TC: We don't want to match on "const" because you could have an literal constant in there, and one would expect it to be consistent with that. The 8472: But I think just supporting the `const` block would be sufficient. It's not exactly what the proposed vec would do but it would be closer than before. Amanieu: I'm inclined to reverse our previous decision here. And say that we instead of changing `vec!` have a method either `Vec::repeat` or `Vec::from_fn`: https://github.com/rust-lang/libs-team/issues/484#issuecomment-2479729832 The 8472: `repeat` already is a method. Amanieu: `Vec::from_fn`. TC: That makes sense to me. Agreed. The 8472: `vec!` tries to mimic the array construction syntax. We can add the method but it doesn't solve that we don't have parity with that syntax. Amanieu: I don't think we should change the macro to do different things based on the syntactic match. TC: Right, if we want it to do what the array constructor does, in my view, we'd have to go all the way, and handle drops, zero cases etc. in the way we've decided for array construction. And that's a bigger change than what's proposed here. The 8472: Sure. `from_fn` is the easy solution. Amanieu: array::from_fn has the index as the fn argument. Should we do that here too? The 8472: Yes. ### (stalled change proposal) rust.tf/libs344 *ACP: Add \`std::string::String::replace\_and\_count\` and/or \`replace\_with\`* Amanieu: There are lifetime issues here. The 8472: So they basically return a `Cow`? Amanieu: Yeah but if you look at the end they say their problems are solved in the regex crate. The 8472: Then close, maybe? The only one remaining is `replace_with`. Amanieu: And regex has this, do we need it in the standard library? The 8472: We'd have a less powerful version since we don't match regular expressions. Amanieu: Yeah. I'm inclined to accept this. ```rust fn replace_with<P: Pattern, S: AsRef<str>>(&self, from: P, mut f: impl FnMut(&str) -> S) -> String; ``` The 8472: What replace functionality we have currently? Amanieu: We have replace. The from/pattern argument is the same. The second argument is just a str. The 8472: The replace functionality is on String only, not str. Amanieu: Pattern doesn't take lifetime anymore (*Amanieu proceeds to remove some lifetimes*) TC: Why would we want this to return `String` rather than returning the `Cow` (the outer return) Amanieu: Because if it replaces the stuff, it returns the string. TC: Wouldn't be better to let the caller coerce it to a `String` from the `Cow` if needed? ```rust fn replace_with<'s, P: Pattern, S: AsRef<str>>( &'s self, from: P, mut f: impl FnMut(&'s str) -> S, ) -> Cow<'s, str>; ``` The 8472: I think so. If the pattern never matches, that's a trivial case to do without allocation. And we can be more fancy and check if the replacement is exactly the same as what's being replaced. But I'm not sure that's worth it. The 8472: So I think returning `Cow` makes sense. And we do it for `from_utf8_lossy`. TC: Does it make sense for the inner closure to return a Cow or an option? Amanieu: I've changed it to a type that implements `AsRef<str>` which avoids the lifetime issues. The 8472: It can also return a static string. TC: Right. Fair enough. Amanieu: We want something that handles the basic usecases and if you're really doing some gnarly things, you can use regex. TC: When writing a recursive descent parser, e.g., I try to not have a dependency on the regex crate. The 8472: You can only match strings, characters or sets of characters. That's it. It's a pretty limited matcher. The 8472: What I'm saying is, this is not the power of regex reaching for here, you just want a bit more powerful replacer. Amanieu: I'm going to reply with the `replace_with` signature on line 547 Amanieu: The lifetime must live as long as the `S`. This is what regex uses. ### (stalled change proposal) rust.tf/libs287 *ACP: Add \`FromByteStr\` trait with blanket impl \`FromStr\`* ### (stalled change proposal) rust.tf/libs111 *Restructure ptr\_metadata to minimal support* ### (stalled change proposal) rust.tf/libs304 *ACP: Avoid the common mistake of \`for x in 0u8..\`* ### (stalled change proposal) rust.tf/libs371 *ACP: primitive numeric traits* ### (stalled change proposal) rust.tf/libs296 *ACP: Designing an alternative \`FromStr\`* ### (stalled change proposal) rust.tf/libs483 *\`Box::new\_from\_ref\` for making a \`Box\<T\>\` from a \`&T\` where \`T: CloneToUninit + ?Sized\` (and \`Rc\` and \`Arc\`)* ### (stalled change proposal) rust.tf/libs395 *\`impl core::str::Pattern for \[&str; N\]\`* _Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_