---
date: 2025-07-29
url: https://hackmd.io/k7ImEzAASUqwSDSpx5T-5A
---

# Libs-API Meeting 2025-07-29

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, The 8472, Josh, Tomas Sedovic, David, Martin, TC

## Agenda

- Triage
- Anything else?

## Project goals

https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/2025H2.20Goal.20Review/with/530407783

### C++ Rust interop problem space mapping

Amanieu: We're asked to review problem statement.

David: I reviewed drafts for this a few months ago.

Amanieu: This is just proposing a problem statement, no concrete proposals yet.

David: I can be the champion for this one.

### SVE and SME on AArch64

Amanieu: I have experience with this, happy to champion this.

Josh: I'm happy to help for the lang side. The biggest blocker is about how difficult it is to introduce the auto traits.

TC: It's also the ??

Amanieu: I'm happy to help with the stdarch part of this.

### build-std

Amanieu: Mainly review RFC draft and decide to approve the RFC. My understanding is most of thework is on the cargo side.

The 8472: I think they're proposing to not introduce any stable changes to the standard library.

Amanieu: I'm happy to champion this on the lib side but there's not much to it.

### Reflection and Comptime

Josh: We generally had lang items be not libs things. So we don't anticipate this not having actual libs asks. We may want to respond with us not anticipating any libs asks.

The 8472: And re experiments any addition would be unstable.

Josh: Yes, this only proposes experiments so nothing stable.

### Evolving trait hierarchies

Amanieu: This adds `Receiver` as a super trait of `Deref`?

TC: This is mostly Lang.

Amanieu: Yes. The libs API is mostly related to the `Receiver` trait.

TC: If libs api is happy with e.g. what module we put it in, then it's mostly lang.

Amanieu: There's still the stabilization but yeah.

TC: Basically we're just splitting up the `Deref` trait. We need that to support arbitrary self types. So we need to break apart the `Deref` trait and for that we need lang features to allow us to do that backwards-compatibly.

The 8472: Where will we dogfood this unstable implementation?

TC: It's going to be a lang experiment.

The 8472: The libs ask is stabilization. So someone will have to use the `Receiver` trait, design APIs around this etc.

TC: There's no material API surface.

The 8472: Who tests this in a real deployment.

TC: The compiler, I think. The Rust for Linux folks as well, as I recall.

Amanieu: Do we need a champion? If it's just asking for a stabilization decision, that's just a libs-api FCP.

TC: I'd volunteer Amanieu in his role as a lang advisor to provide the crossover.

Amanieu: I have been volunteered.

### Finish the libtest json output experiment

Amanieu: I've set this in the past but my personal preference is to fully delegate everything relatedto libtest to the desting devex team. It's very separate from the standard library and doesnt' seem it should be under our umbrella.

Josh: +1

Amanieu: Someone want to champion this and give them blank cheque?

Amanieu: How do we feel about delegating this entirely to libtest? It's a commandline argument to test binaries where the parsing of the argument is in libtest. I think maybe it was Mara who had reservations over delegating over to libtest?

Amanieu: I'll take it and see what happens next week.

## Triage

### FCPs

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

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/140808 *Implement Default for &Option* - (3 checkboxes left)
- merge rust.tf/133289 *Tracking Issue for \`const\_array\_each\_ref\`* - (3 checkboxes left)
- merge rust.tf/143191 *Stabilize \`rwlock\_downgrade\` library feature* - (3 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/65816 *Tracking issue for \`vec\_into\_raw\_parts\`* - (3 checkboxes left)
- merge rust.tf/132968 *Tracking Issue for \`NonZero\<u\*\>::div\_ceil\`* - (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/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* - (3 checkboxes left)
- merge rust.tf/141744 *Stabilize \`ip\_from\`* - (3 checkboxes left)
- merge rust.tf/140956 *\`impl PartialEq\<{str,String}\> for {Path,PathBuf}\`* - (3 checkboxes left)
- merge rust.tf/143717 *Add \`Default\` impls for \`Pin\`ned \`Box\`, \`Rc\`, \`Arc\`* - (3 checkboxes left)
- merge rust.tf/125964 *Tracking Issue for \`core::iter::chain\`* - (3 checkboxes left)
- merge rust.tf/126695 *Tracking Issue for \`array::repeat\`* - (3 checkboxes left)
- merge rust.tf/144054 *Stabilize as\_array\_of\_cells* - (3 checkboxes left)
- merge rust.tf/99108 *Tracking Issue for arithmetic and certain bitwise ops on \`AtomicPtr\`* - (3 checkboxes left)
- merge rust.tf/144091 *Stabilize \`new\_zeroed\_alloc\`* - (3 checkboxes left)
- merge rust.tf/144275 *implement Sum and Product for Saturating(u\*)* - (3 checkboxes left)
- merge rust.tf/63569 * Tracking issue for \`#!\[feature(maybe\_uninit\_slice)\]\`* - (3 checkboxes left)

[Amanieu (2)](https://rfcbot.rs/fcp/Amanieu), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis), [m-ou-se (22)](https://rfcbot.rs/fcp/m-ou-se), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [joshtriplett (20)](https://rfcbot.rs/fcp/joshtriplett), [BurntSushi (22)](https://rfcbot.rs/fcp/BurntSushi)

### (nominated) rust.tf/93743 *Tracking Issue for str::{floor, ceil}\_char\_boundary*

Amanieu: This is a request for stabilization.

The 8472: There's an unresolved question there.

Amanieu: "Should ceil_char_boundary panic when indices are out of bounds?"

The 8472: There's a PR that sets this to return `len` instead.

The 8472: I think the methods are useful. I'd have a usecase for them. I'd like to have them.

Amanieu: Do you think they're fine as they are? Are you happy to start an FCP?

The 8472: I don't think I have the permissions.

Amanieu: Ah, you're on libs not libs-api.

TC: I nominate The 8472 for libs-api.

Josh: I second it.

Amanieu: I'll nominate this for FCP.

### (nominated) rust.tf/99108 *Tracking Issue for arithmetic and certain bitwise ops on \`AtomicPtr\`*

Discussed last week, nominated.

### (nominated) rust.tf/144037 *Rename bool::ok\_or\[\_else\] to bool::then\_ok\_or\[\_else\] to avoid confusion with Option::ok\_or\[\_else\]*

Amanieu: Discussed last week.

TC: I still don't want to do the rename (ref: https://github.com/rust-lang/rust/issues/142748#issuecomment-3104242108). If we're going to start prefixing these with `then_` I'd rather not have these methods at all and instead have a `.opt()` method to lift these into `Option<()>`.

Josh: I agree. I'd keep the methods' names as they are. Effectively any method on `bool` that takes a `Self` would essentially duplicate an existing method (e.g. should we call it `not` or `then_false`?).

Amanieu: I don't mind either. Whatever we choose, people will get used to it.

The 8472: I find the proposal to turn it to `Option<()>`.

Amanieu: The whole point of adding these was that turning it to an `Option<()>` was too verbose.

The 8472: But TC proposed a shorthand method for that.

Amanieu: If you look at the ACP the main concern is that no matter how short you make it it will always introduce a new line.

https://github.com/rust-lang/libs-team/issues/606

Josh: I'd find something like `.opt` more confusing.

The 8472: A bunch of people use one-liners and I guess `rustfmt` is to blame.

Josh: My argument is that `.opt` is confusing. I'd rather use an if. Do we have objections to ok_or_else? We're speculating about other methods? But does this particular method seems good enough?

The 8472: But that argument would work for any method in isolation.

Amanieu: The only unresolved question is whether we rename it to ok_or?

Josh: Is there anyone here who wants to rename the method?

The 8472: No.

Amanieu: I am, very slightly.

Josh: The only reason to having a method is if you find `then_some` too long.

Amanieu: Does someone want to start the rfcbot close on the PR?

Josh: I'll take care of it.

### (nominated) rust.tf/144465 *Allow the global allocator to use thread\-local storage and std::thread::current()*

Amanieu: This changes the internals of thread-local to use the system allocator instead of the global allocator.

The 8472: Do we use the system allocator anywhere else?

Amanieu: pthreads probably uses it internally.

The 8472: I mean in std not some library. Im' mostly wondering how surprising it would be for people if we started using the system allocator more.

Amanieu: No, we don't use it anywhere.

The 8472: So all TLS values would no go into the system allocator, right? Could there be a fragmentation problem?

Amanieu: This is never going to be an issue in practice.

Amanieu: I'm inclined to accept.

The 8472: We're not making any new guarantees. But if we make the change people will depend on it in practice.

Josh: If we're making a change it's probably going to get used. Having an allocator being able to use thread local storage is really important for e.g. pools for memory per thread.

The 8472: If someone's going to use it, they're effectively asking for a guarantee. So we should make it more official. Making docs etc.

Josh: I would expect so, yeah.

The 8472: This PR doesn't do that so we should ask the author to add that documentation.

Josh: Sounds reasonable.

Amanieu: Shouldn't that be the default assumption? That stuff just works?

The 8472: If you're inside the allocator, there are some things you can't use: HashMap, Vec, etc.

The 8472: The stacktracing itself allocates. I think there are other issues.

Josh: I think we should change the team tags from `T-libs` to `T-libs-api` because this needs to be a guarantee. We should start an FCP on it and block it on missing docs.

Josh: I can write up a summary and start FCP if there's no objection.

Amanieu: The alternative is to call the global allocator.

Josh: I've seen hacks like this, but that's a mess.

Amanieu: Yeah, you may have to do that for nostd maybe.

The 8472: Don't our mutexes (the fallback) also use thread-local allocator?

Amanieu: I don't think we have the fallback anymore.

The 8472: Maybe for some niche platforms?

Amanieu: Yeah, we do.

The 8472: This is a fix for one thing that uses a global allocator, but there are others. Should we make a whitelist?

Amanieu: Shouldn't mutexes use the thread-local (??)-allocator?

The 8472: The author isn't asking for that. Im' just saying if you write an allocator and need locks inside, that's another pitfall.

Josh: I think we should document what you can and cannot do in the global allocator. But this is useful on its own. Having systematic guarantees on what will and won't allocate is useful and something we want, but it shouldn't block this FCP.

Amanieu: Thead-local is a particularly diffucilt one because you can't really work around that.

Josh: I've just posted a comment and started an FCP.

### (nominated) rust.tf/144494 *Partial\-stabilize the basics from \`bigint\_helper\_methods\`*

Amanieu: `carrying_add`, `widening_mul` and `carrying_mul_add`.

Josh: Those three seem pretty reasonable. They're only on unsigned.

Amanieu: `carrying_mul_add` seems like the more questionable one. Mainly because I've not seen many uses for it.

Josh: I'm curious to know. But I think this has something to do with FMA (fused multiply add) optimizations.

Josh: Apparently we don't have `mul_add`.

Amanieu: Why are we not stabiliznig the other methods (`carrying_mul` and `borrowing_sub`).

Josh: I'm assuming the reason we need some kind of `carrying_mul` or `carrying_mul_add` it's because it's the counterpoint to `widening_mul`. Is `carrying_mul` just `carrying_mul_add` without the `add`?

Amanieu: Yes.

The 8472: Are there CPUs with `mull_add`?

Amanieu: Yes, arm.

The 8472: Does the arm instruction do anything tricky?

Amanieu: Oh, carrying_mul_add doesn't actually overflow.

The 8482: Because it goes through an intrinsic? Or because it's a hand-rolled implementation.

Amanieu: It goes through

### (nominated) rust.tf/144538 *Tracking Issue for const\_exposed\_provenance*

### (waiting on team) rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16*

### (waiting on team) rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`*

### (waiting on team) rust.tf/144330 *document assumptions about \`Clone\` and \`Eq\` traits*

### (new change proposal) rust.tf/libs630 *Add ASCII\-related methods from \`u8\` and \`MIN\`/\`MAX\` to \`core::ascii::Char\`*

### (new change proposal) rust.tf/libs629 *OnDrop: Simple Drop guard*

### (new change proposal) rust.tf/libs628 *Implement some arithmetic operations for \`std::arch\` SIMD types*

### (new change proposal) rust.tf/libs627 *ACP: \`cast\_init\` method for pointers*

### (new change proposal) rust.tf/libs626 *\`Option::map\_iter()\` to create an iterator from \`Option\`*

### (new change proposal) rust.tf/libs624 *ACP: Proper const \`Deref\` methods*

### (new change proposal) rust.tf/libs623 *Pass file descriptors in std::comand::Command*

### (new change proposal) rust.tf/libs621 *ACP: Add Waker::with\_arc\_wake*

### (new change proposal) rust.tf/libs619 *slice::get\_clamped*

### (new change proposal) rust.tf/libs618 *ACP: Implement fmt::Binary for \[u8\] and friends*

### (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/libs457 *APC: split\_pattern on slices*

### (stalled change proposal) rust.tf/libs262 *Add infallible variant of RangeFrom::next()*

### (stalled change proposal) rust.tf/libs456 *Add Option::todo and Result::todo*

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

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

### (stalled change proposal) rust.tf/libs287 *ACP: Add \`FromByteStr\` trait with blanket impl \`FromStr\`*

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

### (stalled change proposal) rust.tf/libs261 *add \`write\_fmt\` method to String, to make \`write!\` macro work without imports*

### (stalled change proposal) rust.tf/libs133 *Add fmt::Write to io::Write adapter*

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