# Libs-API Meeting 2025-09-09

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

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

Minutes: Tomas Sedovic

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

20 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/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/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/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/141994 *add Iterator::contains* - (3 checkboxes left)
- merge rust.tf/63569 * Tracking issue for \`#!\[feature(maybe\_uninit\_slice)\]\`* - (3 checkboxes left)
- merge rust.tf/145656 *Stabilize s390x \`vector\` target feature and \`is\_s390x\_feature\_detected!\` macro* - (5 checkboxes left)
- close rust.tf/136638 *warn on empty precision* - (4 checkboxes left)
- merge rust.tf/145628 *\[std\]\[BTree\] Fix behavior of \`::append\` to match documentation, \`::insert\`, and \`::extend\`* - (4 checkboxes left)
- merge rust.tf/145610 *Stabilize \`char\_max\_len\`* - (3 checkboxes left)
- merge rust.tf/145722 *implement Extend\<{Group, Literal, Punct, Ident}\> for TokenStream* - (4 checkboxes left)
- merge rust.tf/145948 *Stabilize 28 RISC\-V target features (\`riscv\_ratified\_v2\`)* - (6 checkboxes left)
- merge rust.tf/135889 *Tracking Issue for \`VecDeque::pop\_front\_if\` & \`VecDeque::pop\_back\_if\`* - (3 checkboxes left)

1 rust-lang/stdarch T-libs-api FCPs

- merge github.com/rust-lang/stdarch/issues/1908 *Make some remaining X86 intrinsics safe* - (4 checkboxes left)

[jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [tmandry (1)](https://rfcbot.rs/fcp/tmandry), [the8472 (7)](https://rfcbot.rs/fcp/the8472), [m-ou-se (18)](https://rfcbot.rs/fcp/m-ou-se), [nikomatsakis (3)](https://rfcbot.rs/fcp/nikomatsakis), [scottmcm (3)](https://rfcbot.rs/fcp/scottmcm), [joshtriplett (15)](https://rfcbot.rs/fcp/joshtriplett), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [Amanieu (3)](https://rfcbot.rs/fcp/Amanieu), [BurntSushi (18)](https://rfcbot.rs/fcp/BurntSushi)

### (nominated) rust.tf/libs264 *Ability to stop child process from Inheriting Handles*

Amanieu: The authors were not happy with our proposal to provide an API to provide an explicit handle list. Because there's an "is owned" API that conflicts with this

Chris: We can potentially adjust that API.

Amanieu: The problem with that api is that it's unsafe and you don't really have a nice and convenient way of passing all the handles. It'd be nice to have an API that does that. But I've not gone over all the feedback yet.

Chris: There are two things: API to pass all the handles and potentially also having a way of disabling the default handle

Amanieu: But there's conflict between that and the existing API

The 8472: We can say it's an error case to return both APIs. The spawn_with_process was requested by Tokio apparently. Do they also need this for handle passing?

Amanieu: I don't know.

The 8472: I'm wondering if they still need the API if we have explicit handle passing.

Amanieu: There's one usecase in the tokio docs: allows you to specify a different process as the parent process when spawting a process. That's the only use I could find.

The 8472: So windows lets you reparent a process.

Amanieu: And you inherit all the handles from that process.

Josh: Seems like multiple people on the thread are expressing trepidation about merging the list of specified handles and inherited hangles.

Amanieu: With spawn_with_attributes you can't inspect the attributes.

Josh: I see, this is an opaque handle, not something constructed inside of Rust. Is the problem that spawn_with_attributes the same mechanism that we'd use to pass the list of handles as suggested in the RFC?

Chris: You'd have to use the mechanism.

Josh: Last week we proposed that we pass a list of handles. Seems a large objection is that some kind of merge would have to happen or one would override another.

The 8472: There seems to be a new [UpdateProcThreadAttribute](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute) function that has outparameters where you can get the previous values. So we can pass null there, get the previous value out and then see if something was in there.

Josh: That seems a little bit tortured.

Chris: The out parameter is documented as being reserved for future use.

Amanieu: They did raise a good point: the user-friendly API could be added to the proc attribute builder.

Josh: True, the builder does have a lifetime on it.

Chris: I recall people not loving the spawn_with_attributes API because it's not composable.

Amanieu: That's part of the wishlist for the new Command API with a lifetime: we'd be able to move it as a method on the builder.

Josh: If we imagine that API as we eventually want, do we want to treat this as potential conflict?

Amanieu: Imagine we do have this API. We'd still want to have a way to disable handle inheritance. There are some differences between setting the inherit hangle flag to false and having an empty list. There are security contexts where it triggers if you set the inherit flag to true.

Josh: If call inherit handles and don't pass STDIN/STDOUT do you expect us to add those in or are you expecting to use the full list?

Amanieu: You'd have to set all of them to null (there is a null option for stdio).

Josh: When we talked about spawn_with_attributes, the concept of what if we had more user-friendly thing for specific attributes did come up.

Amanieu: Oh, actually there's no case where we don't inherit STDIN/STDOUT/STDERR. We don't set them to 0

// Open up a reference to NUL with appropriate read/write
            // permissions as well as the ability to be inherited to child
            // processes (as this is about to be inherited).
            Stdio::Null => {
                let mut opts = OpenOptions::new();
                opts.read(stdio_id == c::STD_INPUT_HANDLE);
                opts.write(stdio_id != c::STD_INPUT_HANDLE);
                opts.inherit_handle(true);
                File::open(Path::new(r"\\.\NUL"), &opts).map(|file| file.into_inner())
            }

The 8472: We should look at the bigger picture of how this used in conjunction with the other handles in the process. Those are not inheritable.

Josh: So passing an explicit list doesn't help in any of the items in the list are not inheritable.

The 8472: That's how I understand the last meeting. And it seems like a really poor API design.

Amanieu: right, and there's nothing we can do about that.

Chris: We can require people to explicitly pass them (expect for the stdio) in a future version of the API

The 8472: That's a Windows limitation only though.

Chris: We could duplicate the handles to allow inheritance.

The 8472: But if you have multpile processes spawning concurrently you get a leak.

Amanieu: For stdio we already duplicate the handles and as part of the duplication we mark them as inheritable.

Chris: We have a mutex to stop leaking handles.

Josh: If we did decide to just have the means of controlling the booleans. How could we name it so it's clear that it sets the boolean flag vs. set the handles?

The 8472: Automatic inheritance?

Amanieu: With the new Command API, we would always specify an explicit list of handles for you to inherit no matter what. And we would prevent using handles implicitly.

Josh: Would we still support the boolean in addition to the list?

Amanieu: Yes because you need a way to prevent the stdio handles to be inherited.

Josh: Then maybe we should just consider the boolean for now and assume the handles can be added via spawn_with_attributes and we can do it with the new command api later.

Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/A.20new.20.60std.3A.3Aprocess.3A.3ACommand.60/with/536857747

Tracking issue: https://github.com/rust-lang/rust/issues/145957

Josh: If this is the direction we want to go, I write this up, talk about our future ideas and in the meantime here's what we want to do.

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

Amanieu: I don't think there's a good way to achieve the warnings specifically. Those would happen after trait resolution. It would need custom compiler support.

Josh: I thought last time we've discussed that it would need a compiler support for anything like this.

Josh: I'm looking at the example of doing this in the conditional case and that's a fair point:

fn foo(a: __m256i, b: __m256i) -> __m256i {
    if is_x86_feature_detected!("avx2") {
        a ^ b
    } else {
        // Some fallback code
    }
}

(https://github.com/rust-lang/libs-team/issues/628#issuecomment-3230122399)

Amanieu: If you're using the explicit intrinsic, the plan is for it to emit the warning of "this isn't going to inlined because you're not using the target_feature". It doesn't exist now but its planned.

Josh: That's making a more compelling argument that it's not as straightforward to make these operators as we assumed.

The 8472: So... go use portable-simd?

Amanieu: I still think that's the best approach.

Josh: It would be great to use this, but there are now compelling reasons where this would be really complicated. The original idea was "this seems trivial" and now we're learning of more cases that show it won't be trivial.

Amanieu: Yeah.

The 8472: I still think that if people want to shorter their platform specific code, they should write macros. Rename the imports to shorter names etc.

Amanieu: Or a crate that provides a higher-level simd API.

The 8472: The names are so long because that's what the platform vendors provide. And if the issue is long names, then we don't need to provide the traits.

Josh: I think the original rationalle was less these handles are long. It's more that it's difficult to write math code using math functions rather than operators.

The 8472 to reply

### (nominated) rust.tf/98407 *Tracking Issue for \`Exclusive\`*

Amanieu: Allows you to turn a non-Sync type to a Sync type by only allowing exclusive access. I believe the intended usace is BoxFuture?

Josh: This seems reasonable? This is unconditionally implementing Sync for all values of type `Expclusive`. Should it have a "this is Send if T is Send"?

Amanieu: It should.

Josh: That's not listed in the public API, should it be added?

Amanieu: It's implemented in the code (via autotrait implementation)

The 8472: Should we make it explicit? It doesn't show up in the trait implementations.

Amanieu: It shows in the auto-trait implementations.

The 8472: There are some questions raised at the bottom of the thread.

Josh: The discussion just above this explains why we can't do DerefMut because you can't implement `DerefMut` if you have `Deref`.

Amanieu: I don't know how often this is actually used in practice.

Josh: At least one person responded that they do currently use it in the async ecosystem (it's used in async-compression, a very popular crate).

The 8472: They also mentioned Bevy having something like that.

Josh: Yes and Bevy gives you a shared reference if and only if T is Sync

Josh: This seems fine exactly how it's written. We can't have DerefMut unless that's redesigned. There's the question or what it should be called and where it should go?

Amanieu: Definitely should not be a cell or have "cell" in its name.

Josh: I think `std::sync` is fine as a module location.

Amanieu: `mem`?

Josh: This is related to sync.

Amanieu: seems fine.

Amanieu: People were complaining about the name `Exclusive`. What does Bevy use? `SyncCell`? It's not a cell.

Josh: Agreed, it's not a cell.

Josh: The proposal for `AsMut` seems fine.

Amanieu: If we have `AsMut`, is there any point of having `get_mut`?

Josh: Probably not.

Amanieu: We can add `AsMut` later if we need to.

Josh: Looking at the three questions raised for nomination, I think we can say that we don't need anything changed for nomination. We can talk about that for stabilization.

Amanieu: For `Deref` we would have conflicting methods.

Josh: The requirement to `Deref` is once you've added `Deref`/`DerefMut` you can't add more. If we decided we wanted to add `DerefMut` in the future, we'd have to decide we don't want to add any more methods.

Amanieu: I'd add a `get` method that returns a shared reference requiring T=Sync.

Josh: Would you add that method or would you implement `Deref`?

Amanieu: If we have `get_mut` we would also want `get`.

The 8472: If we add non-exclusive methods to exclusive, we should name it differently.

Josh: The name reflects the usecase that you're turning an Sync to a non-exclusive type. You could add it to a Sync type if you want for generic purposes but otherwise you shouldn't be using this and just use the Sync type directly.

The 8472: Then maybe calling it a `UniqueLock` makes sense?

Josh: It's not really a lock but I see what you mean. If you have `UniqueArc` and `UniqueRc`, this could be a `UniqueSync`. As in this implements `Sync` because it's unique?

The 8472: `UniqueSync` sounds good.

Amanieu: No preference.

Josh: Despite generating the idea, I don't have a preference either.

The 8472: I have a mild preference against `Exclusive` if we're going to add `Deref` or `get`.

Josh: Sounds like we're fine with the location, we're bikeshedding the name but it doesn't seem people have strong opinion and we want to defer impls. Does that okay?

Amanieu: Yeah.

The 8472: Are we going to close the PRs?

Amanieu: Most likely, yes. Unless there's a strong reason to need these traits.

Josh: I think the proposal to do `Deref` or similar should be closed until there's a large endeavor to add it.

Josh: I'll summarize it in the thread.

### (nominated) rust.tf/127213 *Tracking Issue for AVX512\_FP16 intrinsics*

Amanieu: This just needs checkboxes.

### (nominated) rust.tf/140153 *Implement \`Debug\` for \`EncodeWide\`*

FCP finished. Should be merged?

### (nominated) rust.tf/140482 *std::net: update tcp deferaccept delay type to Duration.*

### (nominated) rust.tf/141266 *Stabilize \`substr\_range\` and related methods*

### (nominated) rust.tf/142506 *Add \`Path::has\_trailing\_sep\` and related methods*

### (nominated) rust.tf/144090 *Make \`IoSlice\` and \`IoSliceMut\` methods unstably const*

### (nominated) rust.tf/144871 *Stabilize \`btree\_entry\_insert\` feature*

### (nominated) rust.tf/145504 *Add some conversion trait impls*

### (nominated) rust.tf/145665 *Don't require \`T: RefUnwindSafe\` for \`vec::IntoIter\<T\>: UnwindSafe\`*

### (nominated) rust.tf/145784 `P-high` *\`pin!()\` changed temporary lifetime extension behavior in version 1.88.0 with edition 2024 tail expression temporary scopes*

### (nominated) rust.tf/146013 *Add \`From\` impls for wrapper types*

### (nominated) rust.tf/146099 *Stabilize \`debug\_closure\_helpers\`*

### (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/145722 *implement Extend\<{Group, Literal, Punct, Ident}\> for TokenStream*

### (waiting on team) rust.tf/146009 *Implement \`Receiver\` for \`Exclusive\`*

### (new change proposal) rust.tf/libs651 *ACP: Add API to write formatted data directly into a \`Vec\<u8\>\`*

### (new change proposal) rust.tf/libs650 *Add direct access to the thread id*

### (new change proposal) rust.tf/libs649 *Non\-panicking version of Vec::remove*

### (new change proposal) rust.tf/libs647 *Add \`Waker::from\_fn\_ptr\`*

### (new change proposal) rust.tf/libs646 *ACP: Vec::remove\_ascending*

### (new change proposal) rust.tf/libs645 *\`Pow\` trait*

### (new change proposal) rust.tf/libs644 *ACP: Visitor support for \`std::error::Error\` generic member access*

### (new change proposal) rust.tf/libs643 *\`str::as\_str\` but for \`CStr\`, \`OsStr\`, \`Path\`, and \`\[T\]\`*

### (new change proposal) rust.tf/libs641 *BorrowedFd view types*

### (new change proposal) rust.tf/libs640 *Add \`{UniqueRc, UniqueArc}::into\_pin\`*

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

### (stalled change proposal) rust.tf/libs354 *Add titlecase APIs to \`char\`*

### (stalled change proposal) rust.tf/libs194 *Fix:Introduce an interface to expose the current \`Command\` captured env var logic*

### (stalled change proposal) rust.tf/libs462 *impl fmt::Write for BufWriter*

### (stalled change proposal) rust.tf/libs348 *std::os::unix::env::{argc, argv}*

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

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

### (stalled change proposal) rust.tf/libs457 *APC: split\_pattern on slices*

### (stalled change proposal) rust.tf/libs438 *ACP: \`ForwardInit\<'a, T\>\` to complement \`MaybeUninit\<T\>\`*

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

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