---
title: Libs-API Meeting 2025-07-22
tags: ["T-libs-api", "Libs Meetings", "triage-meeting", "minutes"]
date: 2025-07-22
discussion: https://rust-lang.zulipchat.com/#narrow/channel/259402-t-libs.2Fmeetings/topic/Meeting.202025-07-22/
url: https://hackmd.io/YAPpbe3GTlC-N4a2kStcyA
---

# Libs-API Meeting 2025-07-22

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- Amanieu: we're not getting a consensus, cancel the FCP?
- Josh: Is the complaint that we need to add that we need something to the documentation that shows the value?
- David: Multiple people tried to make PRs that would demonstrate value. But every example would have been better by using `.` or `as` instead.
- Josh: If no one tried to make a PR I'd suggest writing a PR. But if multiple people tried, maybe that shows there's no value here.
- TC: That doesn't sound too hard to write.
- David: That's because you know what you're doing. The people who land here understand it less. They think they need it, but don't necessarily know there are better ways to do this.
- TC: I'm less swayed by "argument of confused people on the internet". There can be value to consistency, and it gives us a place to hang the documentation.
- Josh: It's less about confused people and more that everyone who showed up, wanted this and tried to write it ended up learning there's a better example (such as `*x`). Everyone who thought they needed it ended up realising that they don't.
- TC: I notice @BurntSushi proposed FCP merge; maybe we should ask him.
- The 8472: When you type `*` in the documentation, it points you to a lot of things but it never tells you you can use it for `Box`.
- Josh: Yeah it seems the docs are confusing. We should add an example (ideally one that is not `Copy` e.g. a `String`).
- Amanieu: I find the magic behaviour for Box is not discoverable. Has lang tried changing or generalizing it?
- TC: Are you talking about partial moves?
- Amanieu: Complete moves. That transfer ownership of the inside and then freeze the box.
- TC: There are proposals for generalizing it, but we haven't discussed proposals for removing this recently.
- Josh: Options of unblocking this:
- we could FCP close
- we could ask someone to improve the documentation
- TC: I was tempted to ask the person who asked recently with those +1s why that person wants this, but this may repeat the earlier pattern.
- David: They ended up using `*` instead as well.
- David: It's obvious there's a stabilization issue here but it's not obvious that we want to duplicate an API here.
- TC: Let's say we add it for consistency, add the documentation (that describes the handful of cases you might want this and describes where you don't). If people end up using it in places that would make the code worse, we could always lint on that.
- Amanieu: I don't mind having the function. Maybe just having it would make for a better case for removing a special casing for the box?
- Josh: That brings us back to having a documentation for when you should use it. If the doc will say you don't need to use it most of the time then we don't need it.
- TC: I think it's clear what the docs should say: most of the time you don't use it, the only time you would is `.map(Box::into_inner)` (and similar).
- Josh: It seems to me we're focusing too much on the early example with the map https://github.com/rust-lang/rust/issues/80437#issuecomment-1093664900
- I don't think `.map(|x| *x)` is that bad
- TC: It's the same as `.as_deref()` and similar in that respect.
- TC: I think it's pending on someone who is not a newbie making a stab at a documentation.
- Josh: What is the total value added by this vs. a total value subtracting this? Seems we have have a broad consensus on the value added here is "meh" or occasionally useful.
- TC: All of the really valuable stuff we've added years ago. So a lot of these will be less impactful by default.
- The 8472: You're saying this wouldn't be complete work, we'd add a clippy lint.
- TC: I'm not proposing a clippy lint, just saying we have options if we find this problematic.
- Amanieu + Josh + TC: Time check. Move on and come back to this later.
- 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)

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

### (nominated) rust.tf/63569 *Tracking issue for \`#!\[feature(maybe\_uninit\_slice)\]\`*

Amanieu: Request for stabilization of the first three items: `assume_init_drop`, `assume_init_ref` and `assume_init_mut`.

Amanieu: Sounds good to me.

Amanieu: Other methods are more controversial and should be handled separately.

Josh: Sounds good to me.

Amanieu: I'll start the FCP.

TC: Are you proposing we should not close the tracking issue?

Amanieu: I'd drop slice_*_ptr and I'd open a separate issue for `as_uninit`

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

Amanieu: Currently, these methods are on AtomicPtr and are unstable. We want to add them to `AtomicUsize`. There are issues on the LLVM lowering side but that can be solved on the LLVM side.

Amanieu: Are we happy with the naming of these methods? There's a separate proposal calling them `fetch_wrapping_add` and `fetch_wrapping_byte_add`: https://github.com/rust-lang/rust/issues/99108#issuecomment-3092584065

The 8472: That is consistent with how we do this elsewhere.

Amanieu: It is. But I'd remove the `wrapping` part.

Amanieu: Also personally inclined to remove the `ptr`. To just have `fetch_add` and `fetch_byte_add` for consistency with normal atomics.

The 8472: These are not numeric adds. They don't increment the raw value but rather the size of the value. So you can't compare it to the integer methods.

Amanieu: Sure you can?

Amanieu: We have separate methods for `byte_add`. So that makes it clear this is a method for scale add.

Josh: The distinction is less pointer vs. byte and more pointer vs. target. It's a good distinction to make it clear that you're adding to the pointer and not the value.

Amanieu: That seems like it'll end up a bikeshed over three characters. I feel adding `ptr` is not a great win.

Josh: The fact that we have add and byte add, we should make it consider making it similar to atomic pointers.

Amanieu: There's been a previous issue that was closed because it's error-prone when converting from an atomic integer to atomic pointer where `fetch_add` doesn't do the same thing.

The 8472: That's what I was trying to say.

Josh: That sure sounds like a good argument for not doing it here.

Amanieu: I still think we should have just accepted that FCP (the rename proposal).

The 8472: Why?

Amanieu: It's consistent with everything else: add and byte_add on raw pointers. And I think the consistency is important.

The 8472: We already have `byte_add`. This is about the `add`.

Amanieu: And we have `add` as well. And I don't think `_ptr` adds us anything.

The 8472: The thing is this is not just a pointer, not just a usize. It's an intersection of two things -- and we should name it differently.

Josh: There is acnsistency argument with raw pointers. But having some consistency with raw atomics, but the if you convert code from atomic usize to atomic pointer you end up with code that completely compiles with the same arguments and behaves differently. And when you have to change `fetch_add` to `fetch_ptr_add` you'll see what the problem is.

Josh: I suspect when people have atomic pointer to begin with, `replace` is going to be a common scenario and `add` is not completely impossible, but it doesn't like the most common operation on an atomic pointer.

Josh: Do you think people will have a lot of code where they have pointer and converted it to atomic pointer?

Amanieu: Yes, in the parking lot -- converted atomic usize to atomic pointer.

The 8472: The question Josh asked is converting pointer to atomic pointer.

Josh: We add a doc-alias to `fetch_add` to `fetch_ptr_add`. Right now when you search for `fetch_add`, you'd see it for every pointer type. And that would get you to `fetch_ptr_add` on atomics.

TC: To double check, what are your feelings on `fetch_wrapping_add`?

Amanieu: It's horrible. All fetch_adds on atomics are wrapping. I'd much rather do `fetch_ptr_add`.

TC: Makes sense. I buy that.

Josh: The argument on `fetch_add` is that it's closer to `add` and `byte_add`. The `ftr_add` argument is that you're changing the semantics.

Josh: I'll start the FCP on this.

The 8472: We'll also include the byte and xor right?

(yes)

### (nominated) rust.tf/118260 *Tracking Issue for arithmetic that panics on overflow (\`strict\_\*\` operations)*

Amanieu: Strict arithmetic always panics on overflow.

Josh: That seems fine.

Amanieu: Are we okay with the name `strict`?

Josh: Don't we have instances of that in the past?

Josh: Looks like the only usage of strict in the standard library is entirely these methods.

Amanieu: We're missing a few.

TC: The problem with the wrapper types is that they don't work well but if they did work well, it'd be better what we have here (multiple methods).

The 8472: We could do `0u8.saturating().sub(1)` to save some naming space.

Josh: I suspect the thing people would need most of the time is something like this: `saturated! { x + 1 }` because that'd scale to `saturated! { 2*x + 1}` but that's a radical new design.

TC: I think when we have a type like `NonZero<u64>` we should coerce it to `u64`. That would resolve most of the ergonomic issues. Then we could do the thing The 8472 suggested to move a value into that space, and then the language would take care of moving it out of that space, since that would always be the right thing to do.

Amanieu: It would yes.

Amanieu: `strict_div` and `strict_rem` do we have them on unsigned?

Josh: we do.

Amanieu: `strict_div` on unsigned is identical to normal division.

Amanieu: `strict_neg` on unsigned is assert whether this is equal to zero.

Josh: I see, on sign types it needs to handle the overflow but on unsigned types the overflow can't happen.

Josh: Do we have this on other types? This method can't happen, but it exists for consistency.

The 8472: Didn't we accept an ACP on unsighned types only?

Josh: That was an issue over semantics and not being to agree on them. In this case the semantics are clear but it's completely redundant to add the method over normal division.

Amanieu: For me the first thing that popped into mind was `Box::into_inner`.

TC: I had the same thought.

Josh: If we have precedent to this, go ahead and include them. If not, add those that aren't specifically redundant.

The 8472: The `checked_abs` methods only exist on signed methods.

Josh: Just found a precedent: we have `div_euclid` and `rem_euclid` on unsined types -- which is exactly the same as `div` and `rem`. This is on stable.

Josh: If we had these methods on traits, arguably we'd implement traits on this ones.

TC: We have other interesting ones like `check_negation` and `strict_negation` on unsigned types.

Amanieu: Do we feel these methods are sufficiently useful over checked_add?

Josh: As in compared to just adding `checked_add.unwrap()`?

Amanieu: Yes.

Amanieu: Miri uses `strict` all over the place.

Amanieu: I can see the utility, I checked the box. Is strict the right name for it?

Josh: This is the first instance of strict in the standard library. To me it seems like an immediately evocative name -- as soon as I saw it in the agenda, I knew immediately what it was.

Josh: First, let's do the FCP but I think we should also have the wrapper type.

Amanieu: I hate the wrapper type on principle. They compose poorly. If you want to do wrapping operations on something and then pass it to an API that expects `u64` or operate on a `struct` field that has a `u64`.

TC: The other thing I bring up here is the shift left/right propagate the same error. We've confronted this in another decision somewhere else in some other ACP.

(tomas stepping away for a few minutes)

Amanieu: ...it was actually checked bitshifts. We were going to call it `exact_`.

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

The 8472: we also have exact_div, but that one doesn't return an Option

Amanieu: not a fan of that one. It should return one too, the panicking version should be `strict_exact_div`

Amanieu starting an FCP

### (nominated) rust.tf/125964 *Tracking Issue for \`core::iter::chain\`*

Starting an FCP.

### (nominated) rust.tf/126695 *Tracking Issue for \`array::repeat\`*

(discussion around the position of the `N` argument)

One comparable is: https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html

Starting an FCP.

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

Amanieu: Seems fine to me. It's still unstable.

The 8472: Is there a risk of confusion? Ah, function returns?

The 8472: In `Option::ok_or` turns the option into a `Result`. And in `boolean::ok_or` turns it into a Result. What's the confusion?

Amanieu: It looks like you're handling an option rather than a bool?

TC: That's the whole point.

Amanieu: This would make it more consistent with `then_some` on bool.

The 8472: I think `ok_or` is fine. It treats `bool` as an `Option<()>` (`true` is `Some` and `false` is `None`) and I think that's perfectly fine.

Amanieu: I'm personally slightly in favour of the rename.

TC: It makes it longer and it makes it inconsistent with `Option`.

Amanieu: It makes sense if you think of bool as `true` or `false`.

The 8472: Seems the reporter is confused. They say this makes them think of `Result::ok_or` and that doesn't even exist.

TC: I think of `then` as being monadic propagation, in the same way it's used in `futures` (the crate, [here](https://docs.rs/futures/0.3.31/futures/future/trait.FutureExt.html#method.then)) and that the use on `bool` fits pretty well on that. But if you want to say `then_or_else` then it makes it as much of a sense on `Option` as it does on `bool`. So if we're saying `then_or_else` for bool, we need to rename it on `Option` too (and we don't want that). I'm thinking of `then` like `and_then`.

The 8472: I don't like these methods. The `Option` and `Result` have them differently named. But in this case `ok_or` matches what we're doing on `Option` and I see no reason to rename them.

TC: Agreed.

The 8472: `then` isn't even a good argument becasue it takes a closure.

Amanieu: `then_some` doesn't take a closure. The `ok` is always going to be a unit but you can provide an arbitrary error type.

Amanieu: I have a slight preference for `then` but I'd be happy with `ok_or` as well.

TC: I really want to think about the boolean as it's equivalent in some sense to the `Option<()>` and it breaks my mental model if we start naming them differently.

The 8472: I really don't want to come up for yet another naming divergence so option, boolean and Result have their own little dictionaries.

TC: Agreed.

Amanieu: If you have objections, please write them on the tracking issue to make them visible. And leave this nominated so we'll revisit it next week.

The 8472 will reply.

### (nominated) rust.tf/144054 *Stabilize as\_array\_of\_cells*

Amanieu: This converts from a `Cell<[T; N]]>` to `&[Cell<T>; N]`. `transpose` might be an alternative name (that's also been proposed).

The 8472: It's not a common operation, is it?

Amanieu: We already have `as_slice_of_cells` which is on stable.

The 8472: If we use `transpose` we couldn't have a `transpose` of a slice?

Amanieu: We could but considering `as_slice_of_cells` is already stabilized, I don't think that makes sense.

The 8472: Keep the name as it is.

FCP merge.

### (nominated) rust.tf/144275 *implement Sum and Product for Saturating(u\*)*

Amanieu: The ACP has been accepted.

The 8472: I'm not seeing any documentation?

Amanieu: Feel free to add a new comment.

The 8472: It's insta-stable so FCP is needed.

Amanieu: We did approve this, let's just FCP merge.

Amanieu: Did we decide on short-circuiting or not?

The 8472: We left that open. That's why we should document we haven't decided on a specified behaviour.

### (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/143859 *Guarantee 8 bytes of alignment in Thread::into\_raw*

### (waiting on team) rust.tf/144091 *Stabilize \`new\_zeroed\_alloc\`*

Amanieu: FCP merge?

TC: Does this included `new_zeroed_in`, `new_zeroed_slice`?

Amanieu: Those require allocator API. So it's just `new_zeroed` and `new_zeroed_slice`.

TC: The idea here is that, e.g., we can we ask the allocator to give us zeroed pages?

The 8472: Yes. Also on Linux, this will use the zero page so it'll be an extra page fault because it's lazily mapped. So it's mostly useful for sparse arrays.

..

TC: You could raise a question on naming. Maybe it should be `uninit_zeroed`.

The 8472: It itinialized. You can do `MaybeUninit` and immediately `assume_init`.

TC: That makes sense to me. Let's ship it.

Amanieu: Starting an FCP.

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

The 8472: Commented on that already. Not a fan of the motivation. That leads to similor io empty issues as we had with the job server protocol. The environment variables and the ?? can get out of sync? And the child can open the FDs, write to them and they may be completely different files.

The 8472: With the listener fd the child is unable to check that it's really the correct file it's operating on.

Amanieu: The issue to me seems that it's a range of file descriptors.

The 8472: The better way to do this is to use Unix sockets and check the socket ID and file descriptor.

The 8472: In the fork it will assign random FDs to specific numbers in the child process and presumably they'd have some env vars or CLI args to tell the child process "I gave you these FDs, you can use them now". But you also need to unset closeexec so the descendent tree will inherit the FD, and the child has to set it again. The 8472, otherwise the grandchildren will egt it.

Amanieu: That's the child's problem.

The 8472: But ideally you'd make the protocol more safe to do the right thnig.

Amanieu: In this case the unsafe protocol already exists.

The 8472: This is standard unix stuff a lot of C programs do this. So from the interoperability, this makes sense. But we don't have an alternative so we're leading people to the wrong path.

Amanieu: We should have an API to do this. It's something that's common on various platforms and you have to be able to work with programs there.

The 8472: I don't like that we're introducing the brittle way without having a robust option.

The 8472: Unix sockets are the robust option.

Amanieu: The way I usually handle these things is I receive the file descriptor from the command line and I close it before spawing a child.

Amanieu: I still think we should have some API. Maybe this is not the right API for this. The ordering of the `dup2` actually matters because you're overwriting the file descriptors

The 8472: You can sort the array and do it in the right order.

Amanieu: The array is borrowed. It would have to be a `Vec` inside `Command`.

The 8472: Could we make it an error to pass something overlapping?

Amanieu: In practice you don't have control over the numbers the source file descriptors will be mapped onto.

Amanieu: There can even be a cycle in the FDs, if you want to swap the FDs. It can get quite messy.

Amanieu: Does posix_spawn have something for this? Sounds like yes: dup2.

The 8472: I think we're already using that in STDIN and STDOUT.

Amanieu: And it takes the operations in order. The user is responsible to issue the dup commands in the correct order. In practice what's probably more common is wanting to just say "inherit this file descriptor" and then you can pass the FD numbers as CLI args or env vars. It keeps the FDs numbers.

The 8472: That can be inefficient if you have a process with a lot of FDs and they're high. And the child needs to allocate a big table for this. On the kernel side they use arrays for this, it's not a hash map.

The 8472: I think it's a convention that this stuff is passed in low file descriptors.

Amanieu: I think the API here is wrong. Probably needs more thought. We can discuss this later?

The 8472: Sure, it's from yesterday.

### (new change proposal) rust.tf/libs622 *ACP: Add core::mem::WithDrop to associate a custom drop fn with some data*

Amanieu: This is what people wanted to do with `Box` and custom `drop`. This is basically a `PanicGuard`.

The 8472: It's annoying if you also need to keep pointers in there.

Amanieu: I'm inclined to accept this?

Chris Denton: There's a fair amount of bikeshedding on the name.

Amanieu: There's a lot of different names for this already in use: https://github.com/rust-lang/libs-team/issues/622#issuecomment-3095048199

Amanieu: Ignoring the name, is this something we're willing to have in the standard library?

The 8472 & Chris: +1

Chris: Defer would eat its lunch though (if we had defer).

TC: To pick up the bikeshed for a moment, I think `WithDrop` is nearly perfect. "with" suggests we'll be using a closure here, "drop" suggests we'll not going to be using any new language construct. Many of the alternatives proposed would be a problem, e.g. anything with "defer" steps on the plausible lang work, and something like `WithDrop` avoids that.

The 8472: What about `OnDrop`?

TC: That's the other one that seems plausible, but we use "with" everywhere to indicate "you're passing in a closure to be called".

The 8472: I'm not a fan of that but OK.

Amanieu: Personally DropGuard or PanicGuard because that's what I'm used to. 99% of the time you're actually guarding something.

The 8472: But if you're providing a closure, you have to explicitly define a behaviour. Some of the guards have an implicit behaviour that turns them into a guard. For a general struct, the user has to provide the behaviour.

TC: Scott's proposal is the most fun (Drop bomb, arm/disarm) https://github.com/rust-lang/libs-team/issues/622#issuecomment-3086228311

Amanieu: I don't think that's a great name though.

The 8472: Yeah, it's fun but probably not for public code.

TC: As he said, "too cute".

TC: One of the reasons I like `WithDrop` you're literally associating a function that's going to be executed on drop. You're associating the value "with this drop function".

Amanieu: Yeah, fair. WithDrop is better.

The 8472: I prefer the `OnDrop` but "with" is OK too.

Amanieu: I still prefer `DropGuard`. It feels clearer but I can't tell if I'm just used to it. I guess it's because `DropGuard` is a noun and `WithDrop` isn't?

Chris: `WithDrop` and `OnDrop` are descriptive on what it does.

Amanieu: And `DropGuard` describes what it is.

TC: `DropGuard`?

The 8472: But you're not always *guarding* something. The guard is usually used to uphold some invariant.

TC: `Dropper`? It's a noun, it is the "dropper" of the value. It could be too cute too, but it's also kind of correct.

The 8472: We could just call it `Drop` and it'll be a `struct Drop` instead of `trait Drop`.

Amanieu: That's going to be so confusing.

Amanieu: Just approve it as `WithDrop` and _defer_ the name for later?

Amanieu: Argument in favor of "guard": MutexGuard.

The 8472: But the point is you're not always guarding an invariant. You can also do other things on drop.

Chris: We should approve as-is and leave bikeshedding as a later question.

Josh: I'd expect `DropGuard` to be with no associated data. `WithDrop` sounds like there is a function that will be run.

The 8472: Can we please postpone the naming for later? Josh joined and now we have even more opinion.

Josh: This is an ACP. If we have consensus that we definitely want to have this and the issue is just naming then we should add this and bring the name as an unresolved question.

Amanieu: There's details to discuss other than the name. There's a PR that seems to have been submitted around thes same time and neither the PR nor the ACP saw each other. The PR uses `DropGuard` and has slight differences: the F has a default type parameter (like LazyLock) intended to use for statics but statics don't use drops.

Amanieu: What traits should it implement? My inclination is it should implement just `Debug` (and maybe `Clone`) and nothnig else. `Clone` is the only trait that closures implement.

The 8472: Depends on whether you want to stuff this in a struct that might be around.

Josh: In terms of traits `Deref`.

Amanieu: Of course, that's part of the core functionality (Deref and DerefMut).

Josh: Those make it less important to implement the other traits. That way you can dereference it and `Eq` etc. `Clone`, `Deref`, `DerefMut`, `Debug`.

Josh: I'd also say maybe `Display` if `T: Display`. That might be useful for the same rationale as `Debug`.

Amanieu: If it's something that's user-displayable, you really should write your own struct with your own `drop` implementation.

Josh: Probably right. My immediate thought would be having a numeric ID that needs freeing and wrapping that in a dropping type.

TC: What's the mechanism for coming back for the bikeshed?

Josh: Stabilization?

TC: When we get to the stabilization it feels awkward to rename it right before that. That leaves no time for living with it, collecting feedback on the choice, catching errors, etc. It'd be better to have a process to (presumptively) settle it well before that.

The 8472: We should make it as an open question. Then the stabilization shouldn't happen before that question is resolved.

Josh: This being the third bikeshed, what if we mark issues that need bikeshed. And have the agenda tool do a "bikeshed of the day" at the bottom of the agenda.

TC: That's similar to why I created the `I-lang-bikeshed` label.

The 8472: Regarding `Clone`, in my opinion, `struct`s shouldn't embed this.

Josh: `Clone` can be added later.

Amanieu: I think the `Debug` impl it should just defer to the inner types.

Amanieu: "We're accepting the ACP with some slight modifications: we don't want to default to `FnOnce`. We don't want `Clone` but we want `Deref`, `DerefMut` and `Debug`. As for the name, we've spent a long time on the meeting discussing them and didn't get to a consensus. Here are the candidates: `WithDrop`, `DropWith`, `DropGuard`, (`Dropper`?)".

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

Amanieu: Still an ongoing discussion, let's skip this?

Josh: Let's let people know that we're deferring this given there seems to be an active discussion there and let them tell us when they think it's ready.

### (new change proposal) rust.tf/libs620 *Simple \`fill\_bytes\` function for platform provided secure random generation*

Josh: When we separated out the different concerns for the random tracking issue, we asked to spin out a separate issue for higher and lower level interface.

Josh: The discussion here is whether to add error handling or not. If we don't have a fallible interface, we can just use `RandomSource::fill_bytes`. The "without error hangling" shouldn't exist because we have that.

TC: To be clear I'm not proposing fallibility here. I want a way to know it's not going to block. I don't believe there's a case to be made for it to return fallibly in this low-level OS-noly interface. When we're talking about traits and generic code, I can see fallibility there. But not in the direct OS interface.

Josh: Is the rationalle for the higher-level generic interface for fuzzing or something else?

TC: It's more, e.g., let's say you have an USB hardware random device that could return an error if it detects some fault or its preconditions aren't met.

Josh: If we're talking about low-level interface, you're asking about whether it's going to block or not, right?

TC: The main question discussed on this thread (recently) was whether this be an associated function on the default random source rather than it benig a free function. I made the argument that if we're going to have multiple random source structs, then it makes sense to add these conveniences as associated functions onto those structs rather than having a top-level function to this.

Josh: So e.g. we could have a `would_block` function that would e.g. be part of `DefaultRandomSource` but not `RandomSource`?

TC: Sure. But here, my proposal for is `DefaultRandomSource::fill_bytes` (infallibly).

Josh: What's the difference between that and `.fill_bytes`? Why an associated function rather than a method we have and have to provide?

Josh: For the `fill_bytes` method I argue we shouldn't have it. But I'm for the proposed `would_block` function. We already have `fill_bytes`.

TC: Yes, I'm also happy to defer to the trait-based solution.

TC: And I'm happy to defer the `would_block` function discussion; it's not part of this ACP.

Josh: In practice, we're going to need the `fill_bytes` function on the proposed `RandomSource` no matter what. We will also want `fill_buf` and we might either `try_fill_bytes` that's fallible or ??. But that's not an argument to remove `fill_bytes`. It's an argument to add the fallible version.

Thue 8472: As the goal of the ACP is to try something minimal, we could try with a struct rather than a trait.

Josh: We're presuming we'll have easier time settling this method than we would settling the trait. I don't think one is simpler for the other. We just got to the point where we have an API for random source that's shippable.

Chris: I don't think the argument is about shipping quickly. It's more about hearing from people like RustCrypto who would like to have the free function.

The 8472: In the end whether the method is on a concrete struct or a free method on the module, I'm not sure.

Chris: It's more complicated, you explicitly have to use the trait and import a struct.

Josh: That's an argument for inherent traits. But I see the point.

TC: It's just a way of describing a path to it through the type system.

The 8472: These are automatically filled in by the IDE. I'm not seeing where the problem is. What's the big deal on having an import.

Chris: If you're asking for a security thing, `DefaultRandomSource` is not the best.

TC: We should indeed have a discussion at some point about the names. We probably could do better than that name, and I'd like to talk as well about possibly renaming the trait so that it sits linguistically in a different namespace than likely struct names (e.g. by naming it in verb form).

Josh: When we originally tried to summarize the meeting we had with dhardy, that's where we came to the proposal of "DefaultRandomSource" sounds right but that if you need a fallible low-level function, let's spin that out. So now that it seems we don't need a fallible low-level function, do we need this at all? I agree with The 8472 that there's not really a value in this.

Josh: I don't know whether people arguing on this are arguing because the want a shorter name or whether they think this will be easier to ship than `RandomSource` and `DefaultRandomSource`.

TC: I'm happy to close this and defer to shipping the trait-based solution.

Josh: Any objections to my posting the message above?

The 8472: Sounds ok.

Josh: I will summarize it in the issue.

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

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

### (new change proposal) rust.tf/libs616 *API Proposal: Slice iterator helpers for taking chunks of data*

### (new change proposal) rust.tf/libs603 *A \`Static\` receiver type for dyn\-trait methods that do not take values*

### (new change proposal) rust.tf/libs587 *ACP: \`try\_exact\_div\` method on \`NonZero\<{integer}\>\`*

### (new change proposal) rust.tf/libs575 *ACP: Add Entry\-like API for Option*

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

### (stalled change proposal) rust.tf/libs191 *Add LocalWaker support*

### (stalled change proposal) rust.tf/libs195 *OS\-level \`thread::Builder\` priority and affinity extensions*

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

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

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

### (stalled change proposal) rust.tf/libs111 *Restructure ptr\_metadata to minimal support*

### (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/libs438 *ACP: \`ForwardInit\<'a, T\>\` to complement \`MaybeUninit\<T\>\`*

### (stalled change proposal) rust.tf/libs304 *ACP: Avoid the common mistake of \`for x in 0u8..\`*

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