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), dtolnay (1), BurntSushi (6), scottmcm (1), Amanieu (5), joshtriplett (4), tmandry (1), nikomatsakis (2)

(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:

should we update the docs?
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.

Discussion on team structure, again. Been talking to david wood about compiler team reorganisation. merge libs and libs-contributors, smaller fcp group.
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