---
title: Libs-API Meeting 2025-06-24
tags: ["T-libs-api", "Libs Meetings", "triage-meeting", "minutes"]
date: 2025-06-24
discussion: https://rust-lang.zulipchat.com/#narrow/channel/259402-t-libs.2Fmeetings/topic/Meeting.202025-06-24/
url: https://hackmd.io/pT5paEXZQPG4njGuv_x7MA
---
# Libs-API Meeting 2025-06-24
###### tags: `Libs Meetings` `Minutes`
**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, David, Tomas Sedovic, Chris Denton, TC, The 8472, JoshT
## Agenda
- 2025H2 Project goals
- Triage
- Anything else?
## 2025H2 Project goals
- Proposals open until 2025-07-18
- Submit proposals as PRs to: https://github.com/rust-lang/rust-project-goals/
- Flagship goals: smaller, more specific, bottom-up
- What would you like to see as a flagship goal(s)?
- More details in Niko's email or here: https://hackmd.io/@nikomatsakis/BkOXVTWNle
The 8472: Do we have any goals?
Amanieu: We typically don't have project goals. We're typically the ones being asked for support.
TC: What about the secure random generator? Is that a goal?
Josh: It would probably be a good goal.
Josh: Two benefits of making something a goal: getting regular updates and dedicating bandwidth (for reviews etc.). Things don't have to be goals to get them done.
The 8472: It seems like a big topic, let's make it official to be able to dedicate bandwith to it.
David: Another thing is going to be the proc_macro work stabilized. Lots of people involved, benefit from project tracking, accountability.
TC: That would be a great goal. Also because it intersects with the lang team.
Amanieu: Also the allocator API.
TC: David, would that be you on proc macros?
David: Ideally not. Mara's been interested, she's worked on diagnostics. But I could do it.
David: I have my own goal of getting rustc able to reliably generate valid source code when expanding macros (cargo expand)
TC: It would be good to have oganizational tracking around that work.
Josh: We should also check in with Mara when she's available -- some of the work she's been doing might also make great work.
TC: Does the build-std work intersect with libs-api?
Josh: One of the things build-std has been doing to manage scope is saying any kind of configuration of the standard librery is currently out of scope. So that work currently has changes to the standard library's surface area.
TC: On Rust for Linux one of the project goal items around configuring `no_std` externally.
The 8472: What does "externally configurable" mean?
TC: Injecting configuration into crates.
https://github.com/rust-lang/rfcs/pull/3791
Josh: If the're looking at making a change like that, that would be something we need to discuss with us. We should be looking at that goal and see if that's something we want to approve.
## Triage
### FCPs
1 rust-lang/rfcs T-libs-api FCPs
- merge rust.tf/rfc3809 *RFC: enable \`derive(From)\` for single\-field structs* - (4 checkboxes left)
12 rust-lang/rust T-libs-api FCPs
- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/140881 *Tracking Issue for duration\_constructors\_lite* - (3 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/129333 *Tracking Issue for \`lazy\_get\`* - (3 checkboxes left)
- merge rust.tf/141840 *If \`HOME\` is empty, use the fallback instead* - (3 checkboxes left)
- merge rust.tf/127213 *Tracking Issue for AVX512\_FP16 intrinsics* - (3 checkboxes left)
- merge rust.tf/136306 *Tracking Issue for NEON fp16 intrinsics* - (3 checkboxes left)
- merge rust.tf/141520 *Tracking Issue for const {OsString, PathBuf}::new* - (3 checkboxes left)
- merge rust.tf/70530 *Tracking Issue for {BTreeMap,BTreeSet}::extract\_if* - (3 checkboxes left)
- merge rust.tf/141994 *add Iterator::contains* - (4 checkboxes left)
- merge rust.tf/141744 *Stabilize \`ip\_from\`* - (3 checkboxes left)
[scottmcm (2)](https://rfcbot.rs/fcp/scottmcm), [nikomatsakis (3)](https://rfcbot.rs/fcp/nikomatsakis), [joshtriplett (10)](https://rfcbot.rs/fcp/joshtriplett), [Amanieu (3)](https://rfcbot.rs/fcp/Amanieu), [BurntSushi (9)](https://rfcbot.rs/fcp/BurntSushi), [tmandry (1)](https://rfcbot.rs/fcp/tmandry), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [m-ou-se (10)](https://rfcbot.rs/fcp/m-ou-se), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726)
### (nominated) rust.tf/130703 *Tracking Issue for secure random data generation in \`std\`*
### (waiting on team) rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`*
### (new change proposal) rust.tf/libs608 *Add \`into\_unique\` method to \`Rc\` and \`Arc\`*
Amanieu: This seems fine. Thoughts?
Josh: Should this return `Option<T>` or `UniqArc<t>`
Amanieu: This should return `UniqArc`.
Josh: Then this should return the `UniqArc`. That's not what the proposal says but it should do.
Josh: I'd be happy to write-up a quick summary saying we'd like to integrate this `From<UniqArc>`.
Amanieu: The commeent form @zachs18 mirrors what I'm thinking and I'd like to see that addressed: https://github.com/rust-lang/libs-team/issues/608#issuecomment-2988714142
[...]
Amanieu: If we have a version that clones, would we call that `make_unique`?
Josh: Yes, instead of `make_mut` we'd have `make_unique`.
TC: Regarding naming, we do have an unstable `Unique` type.
Josh: The proposed one here are `UniqueArc` and `UniqueRc` so those are sufficiently... unique
Amanieu: `UniqueArc` is implemented.
TC: Would `UniqueArc` type be no-alias and dereferencable?
Amanieu: It would be dereferanceble. It's an Arc with only one referenc.
TC: So this type could be more like `Box` and so we could make it `noalias` and dereferncable.
Amanieu: There's still an open question on the `Box` side is how much it can be `noalias`.
TC: It is, but one complication is that we haven't done it on some of the other types.
Amanieu: Doesn't apply here. You can have weak references to the underlying allocation. Those references are only allowed to access the ref count part not the data part. But that still means there are multiple references so it's not `noalias`.
Amanieu: Should we mark this as accepted?
Example:
```rust!
impl<T> [T] {
pub const fn split_at_pin(self : Pin<&Self>, mid: usize) -> (Pin<&Self>, Pin<&Self>);
pub const fn split_at_pin_mut(self : Pin<&mut Self>, mid: usize) -> (Pin<&mut Self>, Pin<&mut Self>);
}
```
Further discussion here about *not* using arbitrary self types, and instead using an impl block for `Pin<[T]>`.
Josh: Does deref work there, or do we have to write `Pin<&mut [T]>` and `Pin<&[T]>` too?
*we did*
### (new change proposal) rust.tf/libs607 *ACP : Enshrine the fact that slices are structurally pinning through safe accessors*
Amanieu: This is basically pin projection.
The 8472: If we have special pin api for slice operations, would we then have to replicate a lot of the other slice APIs as pinned versions too?
Amanieu: Potentially, yes.
The 8472: That doesn't sound fun.
Josh: If we wanted this, I don't see how a language change would make this simpler.
Josh: `chunks` vs. `chunks_mut` we'd have `chunks_pinned` and `chunk_pinned_mut`.
TC: That's the right way to think about it -- like mutability -- in terms of naming.
Amanieu: I'm really not seeing any good solution other than replicating the entire slice API.
Josh: It's worth explicitly saying that we have to systematically add them all? Or add the few useful ones and then add more as people ask?
The 8472: If people ask piecemeal over the years, we may end up replicating 30% of it over time. What's the end state here?
TC: The end state is probably having `_pin` variants in a significant portion of areas where there are `mut` variants.
The 8472: There has been a discussion in in-place initialization around out references.
TC: There are two proposals: one from Alice that uses the trait system and Taylor Cramer's which uses out references.
The 8472: I was thinking that someone might want to split a slice (of out refs) and do a parallel initialization.
TC: On this ACP, it seems well motivated. I'd change one thing on the naming -- to say "pin" rather than "pinned" to match the likely language syntax -- and accepting it.
Amanieu: Should these methods be implemented on `Pin<[..]>` or methods on the slice directly?
Josh: I'd have expected it to be methods on the slice that took `&pin mut` rather than `&mut`.
Amanieu: Do we allow pin on arbitrary self types?
Josh: I think Pin allows self types not requiring arbitrary self types.
Amanieu: So that means these should be on the slice type itself.
Josh: That's what I was thinking.
Amanieu: I'm inclined to accept this for all slice methods. E.g. binary search could have a pin version. Does pin only matter for mutable references or for immutable ones as well?
TC: For both.
Josh: IIRC rustdoc pays attention to which block you put a group of methods to.
Amanieu: Yes, you can group things.
Josh: No objections, but it should be in a separate impl block so you don't double the length list.
The 8472: It will still show up alphabetically in the sidebar.
Josh: Sounds like a quick feature reuqest to rust doc to be able to group things.
TC: Wouldn't that be more confusing? I'd rather have it alphabetical and, if we want to hide pinning from people who don't care about it, have a checkbox for that.
The 8472: It's not just pinning. A lot of slice things show up in the docs for ascii char or box or maybeuninit. If you're just looking for the slice methods, there's a lot of noise already.
Josh: I'm suggesting that if we approve something that may add 50 new items, we should get in touch with the rustdoc team.
Josh: No objection to approving this. Here's the structure of the signature this should look like (e.g. `Pin<&mut self>`). But also reach out to the rustdoc team.
TC: And change `pinned` to `pin` everywhere.
TC to write comment.
The 8472: If they're on a different Self type, do we need separate names?
Josh: That's a good point. If we don't have them as methods on slices directly, we might be able to do that.
TC: Are we okay approving the `IntoIterator` impls too?
Amanieu: IntoIterator is fine.
The 8472: Could we implement this directly on an impl block of `Pin<&mut [T]>`?
Josh: It's possible you'd be able to write that that way and give the methods the same names? I'm not sure about the pseudo arbitrary self types and deref.
TC: I think so. We can reuse the names; we just need to think about the effect on method resolution.
Josh: It seems okay to use the same names, because in the case you have `Pin<[T]>` you wouldn't be able to call the regular methods anyway. And that might solve the rust doc issue as well as it would have it in a separate block.
The 8472: It would end up in the pin page rather than the slice page.
Josh: So we still need to talk to rustdoc.
### (new change proposal) rust.tf/libs605 *impl \`AsRef\<\[T; N\]\>\` and \`AsMut\<\[T; N\]\>\` for \`\[T; N\]\`*
### (new change proposal) rust.tf/libs604 *Implement (non\-short\-circuiting) \`Sum\` for \`Saturating\<\_\>\`*
Amanieu: This is not straightforward. If we have a slice of [int::MAX, int::MIN] what is the saturating sum of that? If you were operating with the infinite precision, the answer would be zero.
Josh: We could implement this for all the saturated unsigned types and not implement the signed ones because that's hard. And that would solve the motivating use case.
Amanieu: This was proposed in ACP 303 which was closed.
Josh: That one was closed because there was a long discussion around short-circuiting. This one is different (non-short-circuiting).
The 8472: In the previous one I was mainly concerned about the performance of u8 or u16 types since they saturate easily. If you have huge types like `u64` it's less likely you'd saturate. It's question on the shape of the data on whether short-circuiting is beneficial or not.
The 8472: If we can do this by doing chunk-wise processing it can be faster than doing precise short-circuiting, because it could be parallelized.
Josh: So technically allow but don't require short-circuiting.
Amanieu: But it's technically observable if you have e.g. `map` with side effect.
Josh: We're approving for unsigned, don't approve for signed. We don't make any guarantees around short-circuiting. It's allowed to but not guaranteed to short-circuit.
The 8472: That would be the first time we don't make such a guarantee in the standard library.
Josh: That doesn't seem like an argument against the API. Why don't we approve the ACP and say this is an unresolved question.
The 8472: If we start with an underspecified API we can make it stricter in the future.
The 8472: From a performance perspective I'm happy about it. I just don't know how many people care about side effects here.
Josh: We know this will need FCP. So why don't we approve this and discuss the short-circuiting in the FCP.
Amanieu: Either way if you care about being explicit, a `fold` over `checked_add` or `saturating_add` would do short-circuiting or not as you prefer.
The 8472: So we can keep the flexibility because the users have a way out.
Josh: That seems fine to me.
### (new change proposal) rust.tf/libs603 *A \`Static\` receiver type for dyn\-trait methods that do not take values*
### (new change proposal) rust.tf/libs602 *ACP: add \`array::from\_raw\_parts()\`*
### (new change proposal) rust.tf/libs589 *\`ptr::fn\_code\_ptr\` for explicitly getting an opaque pointer of a function*
### (new change proposal) rust.tf/libs587 *ACP: \`try\_exact\_div\` method on \`NonZero\<{integer}\>\`*
### (new change proposal) rust.tf/libs578 *ACP: hash\_map! macro to create \`HashMap\`s such as \`vec!\`*
### (new change proposal) rust.tf/libs577 *Option::try\_get\_or\_insert\_with*
### (stalled change proposal) rust.tf/libs191 *Add LocalWaker support*
### (stalled change proposal) rust.tf/libs371 *ACP: primitive numeric traits*
### (stalled change proposal) rust.tf/libs295 *Create iterator function in std libs: split\_item\_mut()*
### (stalled change proposal) rust.tf/libs457 *APC: split\_pattern on slices*
### (stalled change proposal) rust.tf/libs347 *Context reactor hook*
### (stalled change proposal) rust.tf/libs456 *Add Option::todo and Result::todo*
### (stalled change proposal) rust.tf/libs462 *impl fmt::Write for BufWriter*
### (stalled change proposal) rust.tf/libs262 *Add infallible variant of RangeFrom::next()*
### (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/libs111 *Restructure ptr\_metadata to minimal support*
_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_
Sign in with Wallet
Connect another wallet