---
date: 2025-04-01
url: https://hackmd.io/GO-m8mYWRbeFaJ7lBd6nPw
---

# Libs-API Meeting 2025-04-01

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, David, JoshT, Mara, The 8472, Chris Denton, TC

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/138498 *Implement Deref\<Target=ByteStr\> for CStr* - (3 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/130823 *Tracking Issue for \`non\_null\_from\_ref\`* - (3 checkboxes left)
- merge rust.tf/137280 *stabilize ptr::swap\_nonoverlapping in const* - (3 checkboxes left)
- merge rust.tf/122661 *Change the desugaring of \`assert!\` for better error output* - (3 checkboxes left)
- merge rust.tf/137992 *Stabilise \`os\_string\_pathbuf\_leak\`* - (4 checkboxes left)
- merge rust.tf/115585 *Tracking issue for \`cfg\_match\`* - (2 checkboxes left)
- merge rust.tf/138016 *Added \`Clone\` implementation for \`ChunkBy\`* - (3 checkboxes left)

[m-ou-se (4)](https://rfcbot.rs/fcp/m-ou-se), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [BurntSushi (6)](https://rfcbot.rs/fcp/BurntSushi), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [Amanieu (5)](https://rfcbot.rs/fcp/Amanieu), [joshtriplett (4)](https://rfcbot.rs/fcp/joshtriplett), [tmandry (1)](https://rfcbot.rs/fcp/tmandry), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis)

### (nominated) rust.tf/libs358 *Update Windows exe search order (phase 2)*

Amanieu to post summary

### (nominated) rust.tf/74985 *Tracking Issue for slice::array\_chunks*

-> Only the as_chunks methods.

Amanieu to start FCP for that.

### (nominated) rust.tf/75942 *Documentation for \`std::fs::set\_permissions\` doesn't cover symlink behavior*

JoshT: two questions:

1. should we update the docs?
2. should we change the behavior?

Amanieu: symlinks are rarely used on windows. the windows behavior isn't a big issue. more concerned abotu changing the unix behavior. don't think the CVE is directly relevant.

JoshT: right answer is probably to document what it does. We can add it to the platform-specific behavior section, with a guarantee about what will not change in the future about symlinks.

Amanieu: fchmodat doesn't support not following symlinks.

JoshT+Amanieu: Just document and move on.

Amanieu: Ask the author if this has an effect on WASI.

### (nominated) rust.tf/98990 *#\[deprecated\] lint doesn't trigger when overriding deprecated method*

The 8472: would be a problem if it isn't optional to implement.

JoshT: Yeah, if it is required, you shouldn't get a warning.

JoshT: if you want to deprecate calling it, you may or may not want to warn implementers. both are reasonable.

JoshT: emitting the warning on implementation is fine. you can always add allow(deprecated). not much harm

David: Agree. If anyone has a case for only deprecating call but not impl, or impl but not call, that should use a different attr. E.g. `#[deprecated(call)]`, if someone can justify that.

JoshT: I can see more benefit to deprecating an impl than deprecating the call. E.g. if it was a mistake to let a method be overridden.

Amanieu: I don't think deprecation is the right tool here.

The 8472: What's the benefit of warning the implementor. R-A already doesn't implement the default methods for you. Someone would need to go out of their way to implement it.

JoshT: The goal of adding it would be to push people to remove it.

The 8472: do we need people to unimplement methods?

Amanieu: no, not really

The 8472: then what's the benefit?

Amanieu: because people copy existing code, so will keep implementing these methods

Amanieu: i think if calling it is deprecated, implementing should also be.

David: i'm on board with that.

Mara to hand over to lang.

### All-Hands

Mara: What do we want to do at the all-hands?

JoshT: We should discuss in advance what our top priorities are for things to be implemented. E.g. delegation, inherent traits, etc. Things we want from other teams.

Mara: Before the all-hands? Or at the all-hands?

JoshT: Either works. We can do it here, online, to have more time coordinating with other teams.

David: If there's a room dedicated for libs, we'd find a use for it. Even just as a home base.

Amanieu: Can think of two things. Organisational things.

1. Discussion on team structure, again. Been talking to david wood about compiler team reorganisation. merge libs and libs-contributors, smaller fcp group.
2. Coordinate with other teams about procedures. E.g. triage. How we do fcps, etc. We do things differently than other teams. If that works better for us, we can keep doing that.

The 8472: do we have project goals we should coordinate?

https://rust-lang.github.io/rust-project-goals/2025h1/goals.html

Mara: What about our subteams/wgs?

- crate maintainers
- portable simd
- allocator

Amanieu: allocator needs a champion to drive it forwards.

Mara: crate maintainers and portable simd in a separate room? or shared in a single libs room? single room probably makes most sense.

JoshT: We should discuss (wg-)async in the libs room. Enough libs specific items.

David: Specifically AsyncIterator/Stream should get resolved

JoshT: What AsyncRead/Write should look like.

### (nominated) rust.tf/111137 *Tracking Issue for AVX512 intrinsics*

### (nominated) rust.tf/130703 *Tracking Issue for secure random data generation in \`std\`*

Discussion ongoing.

(Some discussion about the current state, and whether we want to have random APIs in the standard library or only in the ecosystem.)

JoshT: At some point there'd be value in us commenting on how much we think should be in the standard library.

### (nominated) rust.tf/130994 *Tracking Issue for File lock API*

agenda generator bot: FCP finished. Should be merged?

Josh: Was merged, then reverted due to issue with the API. We should discuss it.

JoshT: We FCP'd this. After it was stabilized but before it shipped in stable, someone noticed the try_lock API was error prone. The `?` strips the `#[must_use]`. Too easy to accidentally ignore the boolean.

JoshT: Should we change the API to make it less error prone?

Mara: We could use a new (must_use) enum instead of bool.

JoshT: Downside is that you'll have to call .lock_succeeded() or similar.

Burntsushi (on github): I think Result<(), TryLockError> is probably the right call here. A nested Result is weird IMO.

The 8472: We could return something that isn't Try at all. Some LockOutput that has methods for different use cases. Could become a Result for the success case or error case. Could cover everything.

JoshT: Seems somewhat cumbersome.

dpc (github): https://doc.rust-lang.org/std/sync/type.TryLockResult.html

Mara: Mimicing mutex' api makes sense to me.

Amanieu: i don't really care how try_lock failed. fine to inspect the error kind.

Amanieu: Do we need TryLockError? can this just be io::Error with an errorkind for this?

JoshT: Don't want to rely on the underlying syscall never producing whatever errorkind we pick.

Amanieu: my point is that the syscall already returns an error code if it fails to lock the file.

JoshT: Don't want to have to triple check the docs to know which kind to match on.

### (nominated) rust.tf/134446 *Stabilize the \`cell\_update\` feature*

### (nominated) rust.tf/137198 *Rename \`cfg\_match!\` to \`cfg\_select!\`*

### (nominated) rust.tf/137487 *Stabilize \`assert\_matches\` and move it to \`core::macros\`*

Amanieu: It's unfortunate we're working around the glob import people have made here, and that we can't prioritize the standard library one.

TC: How bad is the breakage? Let's ask someone to do a crater run. If it's not that bad, we could just ask for PRs to be made to affected crates.

Amanieu: Yes, let's. Also, what would lang think about changes the rules for all crates such that macros in the crate root aren't pulled in automatically?

TC: That seems a worthwhile discussion.

Amanieu: If we could make it so that the macros are all included in the normal prelude and get rid of the other mechanism, then we could just include `assert_matches` in the Rust 2025 prelude.

TC: In terms of cleaning up the language definition, it would be nice to get rid of the macro prelude. We have to document that separately in the Reference, e.g. Also, there's that thing we identified in the last edition about some macros not having paths separately from the prelude path. We should clean that up also.

Amanieu to write up the plan we discussed.

### (nominated) rust.tf/137654 *Debug impls of ExtractIf have inconsistent trait bounds*

### (waiting on team) rust.tf/136687 *Improve the documentation of \`Display\` and \`FromStr\`, and their interactions*

### (waiting on team) rust.tf/136912 *Add missing trait implementations for ScopedJoinHandle*

### (new change proposal) rust.tf/libs569 *ACP: abstract \`BufReader::peek\`*

Amanieu/TC/The 8472: (We discussed and weren't sure it solved the problem.)

Amanieu: I'll write it up.

TC: For ACPs like this, it'd be nice if the author would include a minimal reproducible mockup in the playground. To be sure this API makes sense, I'd need to mock it up. But the ACP author should have already done it for me. If I were submitting an ACP, I'd have done that before submitting to be sure about my proposal and that I could explain it.

Amanieu: We don't want people to have to implement things ahead of the ACP though.

TC: The mockup wouldn't need all the forwarding impls and other bells and whistles that take the time to get right when doing a real impl. It just has to demonstrate the main point.

The 8472: Yes, and in many cases, things could be entirely stubbed out and still demonstrate the point.

### (new change proposal) rust.tf/libs568 *Implement \`Read\` and \`Write\` traits for \`BorrowedFd\` and \`OwnedFd\`*

### (new change proposal) rust.tf/libs562 *Add ability to customize STARTUPINFO structure in Command API*

### (new change proposal) rust.tf/libs559 *Expose \`.set\_flags()\` on Posix \`CommandExt \`*

### (new change proposal) rust.tf/libs558 *Use \`TEB\` to get process information on Windows*

### (new change proposal) rust.tf/libs557 *Add \`iter::Peekable::next\_unpeek\`*

### (new change proposal) rust.tf/libs556 *fs::append*

### (new change proposal) rust.tf/libs555 *Add \`std::io::Seek\` instance for \`std::io::Take\<T\>\` when \`T: Seek\`*

### (new change proposal) rust.tf/libs554 *Add \`std::process::Output::exit\_ok\`*

### (new change proposal) rust.tf/libs553 *Add a "shrink\-if\-excessive" API to \`Vec\`*

Amanieu: We'd have to document the behavior rules for this shrinking; people would rely on it.

The 8472: Not necessarily. We don't document our growth heuristic. This is the inverse of that. We could see it as the equivalent of shrinking to fit and then reserving one element, invoking that growth heuristic. But I'm not sure why people would want this. It seems like a niche pattern to want to shrink while leaving extra capacity.

TC: I've written this many times. It's not about wanting to leave extra capacity after shrinking, exactly. It's more about wanting to not shrink at all unless the capacity is much too big. Then you can just call `shrink` in a loop and it automatically keeps the capacity in check.

The 8472: Ah, that makes sense. We might want some hysteresis there for optimal behavior.

TC: Yes, and that's one reason it'd be good to have this, is that it is non-trivial to implement correctly.

The 8472: Yes, I'm not opposed to having this.

### (stalled change proposal) rust.tf/libs372 *ACP: env::home\_dir replacement*

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

### (stalled change proposal) rust.tf/libs155 *Arbitrary alternate flags in \`std::fmt::Formatter\`*

### (stalled change proposal) rust.tf/libs344 *ACP: Add \`std::string::String::replace\_and\_count\` and/or \`replace\_with\`*

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

### (stalled change proposal) rust.tf/libs333 *\`NonNull::{from\_ref, from\_mut}\`*

### (stalled change proposal) rust.tf/libs363 *Un\-specialize impl ToString*

### (stalled change proposal) rust.tf/libs295 *Create iterator function in std libs: split\_item\_mut()*

### (stalled change proposal) rust.tf/libs383 *Add \`FRAC\_1\_SQRT\_2PI\` constant*

### (stalled change proposal) rust.tf/libs192 *Report allocation errors through the panic handler*

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