---
date: 2025-02-04
url: https://hackmd.io/xLRjfOA4Twy3_nEzXv7gcQ
---

# Libs-API Meeting 2025-02-04

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/135933 *Explain how Vec::with\_capacity is faithful* - (3 checkboxes left)
- merge rust.tf/130192 *\[discussion\] \`ErrorKind::InvalidFilename\` from \`io\_error\_more\`* - (3 checkboxes left)
- merge rust.tf/129375 *Tracking Issue for unbounded\_shifts* - (3 checkboxes left)
- merge rust.tf/127534 *feat(core): impl Step for NonZero\<u\*\>* - (3 checkboxes left)
- merge rust.tf/59618 *Tracking issue for HashMap::extract\_if and HashSet::extract\_if* - (3 checkboxes left)
- merge rust.tf/134340 *Stabilize \`num\_midpoint\_signed\` feature* - (3 checkboxes left)
- merge rust.tf/103806 *Tracking Issue for \`string\_extend\_from\_within\`* - (3 checkboxes left)
- merge rust.tf/128101 *Tracking Issue for \`unsigned\_is\_multiple\_of\`* - (3 checkboxes left)
- merge rust.tf/134213 *Stabilize \`naked\_functions\`* - (6 checkboxes left)

[traviscross (1)](https://rfcbot.rs/fcp/traviscross), [joshtriplett (3)](https://rfcbot.rs/fcp/joshtriplett), [Amanieu (7)](https://rfcbot.rs/fcp/Amanieu), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis), [m-ou-se (8)](https://rfcbot.rs/fcp/m-ou-se), [BurntSushi (9)](https://rfcbot.rs/fcp/BurntSushi), [scottmcm (2)](https://rfcbot.rs/fcp/scottmcm)

### (nominated) rust.tf/libs246 *ACP: replace use of \`Pointee\` trait with a \`ptr::Metadata\` type*

Discussed a while back.

Amanieu: I was supposed to reply, but now forgot the context.

David: None of these signatures contain `usize`. Previously you could get the `usize` out for a slice, but now you can't.

David: We should get a compiler person in the room.

The 8472: https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.len is stable

David: The point is to be able to make a function that is generic over pointer types.

The 8472: Right, len method wouldn't work for pointers to (unsized) structs that end in a slice.

Amanieu: current API: https://github.com/rust-lang/rust/issues/81513

Amanieu: Should we replace this?

Mara: Not convinced

David: Not convinced either. Could be convinced by a compiler person saying that it's easier to stabilize.

The 8472: Let's ask for more details.

TC to reply to ask CAD97 or another representative to join the next meeting.

### (nominated) rust.tf/libs524 *Require a LintId for all proc\-macro warnings*

Adds fourth macro for in proc_macro crate: `#[proc_macro_warning]`

Use it on a static. Gives an item that rustdoc can render. A way to put a warning into the module system.

The warning function takes such a lint id.

MVP. Future possibilities can all be built on top of this.

The 8472: Should this be a `static` or a `const`?

Amanieu: Doesn't matter much, it's kinda magic. Static makes sense, because it can't be access from a const fn in the proc macro crate.

David: Doesn't make a difference.

Mara: How about deny-by-default or allow-by-default?

David: Would be an argument to proc_macro_warning.

Mara: proc_macro_lint then?

David: Two things to name are: `proc_macro_warning` and `LintId`. Should probably use the same word.

Mara: Can't have a lint with a name of something that is already a value in the root of the proc macro crate.. Not sure if that's a problem.

David: Correct. Don't think that's a problem.

Amanieu: LintId or Lint?

LintId seems fine.

TC: The new attribute should be nominated for lang; doing it on the PR is OK.

David to update PR and nominate for lang.

### (nominated) rust.tf/62280 *Tracking issue for \`slice\_take\`*

Nominated by cramertj asking us to decide on a name (take/extract/split_off/..) and to pick a name for the trait (OneSidedRange/SplitOffRange/..)

Mara: Would love to have these, but not sure about name.

The 8472: Example where we would use this: https://doc.rust-lang.org/1.84.0/src/core/slice/iter.rs.html#732-738

Amanieu: "take" is terrible.

TC: Why? Maybe articulating that will help lead us to a better name.

David: Implied similarity with Option::take and mem::take is wrong. It's closer to "split" etc. split_off is a more promising direction.

Amanieu: There's a comment that says we might not need the trait. Instead, use different method for taking from front and taking from back.

Mara: Makes sense to me.

"take" is in conflict in naming with io::Read trait: https://github.com/rust-lang/rust/issues/62280#issuecomment-1574882463

Mara: What was the argument against split_off?

Amanieu: We could call it `pop` for taking one element. And `split_off` for multiple.

Amanieu: Could be confusing. Newcomers might be confused that `pop()` doesn't pop from the Vec that you took the slice from.

Mara: Prefer split_off_first, to be consistent with split_first.

Amanieu: split_off with OneSidedRange vs two methods (for from front and from back)

Mara: Name I didn't see is "cut_off"

The 8472: or just "cut"

Mara: Prefer range syntax. I feel like i'd be more likely to get them swapped in my head if i had to name them before/after (or front/end, w/e).

The 8472: And we can support inclusive ranges.

David: I like the split_off name (split_off_first, etc.), and having the OneSidedRange trait.

Mara: I like split_off or cut_off, and using the trait.

Amanieu: Prefer split_off.

Consensus.

Mara: Only thing left is the name of the trait.

David: OneSidedRange sounds fine.

Amanieu: Sounds fine.

Consensus.

David to reply.

### (nominated) rust.tf/125882 *Tracking Issue for \`integer\_sign\_cast\`*

Naming: cast? to? ..?

Mara: Prefer "cast".

David: Yeah current names are fine.

Amanieu: prefer "as". implies in place conversion.

The 8472: They are Copy. Doesn't really make a difference.

David: "cast" was inspired by pointer methods to convert between mut and const. In those cases, "as_mut" won't have worked.

Mara: "as_" shouldn't just make a negative number positive or something. "cast_" seems right for this type of conversion.

David: Agree. Imagine i16::as_i8. Should return Option.

Amanieu: Also see https://github.com/rust-lang/libs-team/issues/453

TC: We call this operation casting in the Rust Reference. Specific casts might be called 'sign extension' or 'truncation', but the operation in general is called casting.

https://doc.rust-lang.org/nightly/reference/expressions/operator-expr.html?highlight=cast#type-cast-expressions

The 8472: For people not coming from C(++), "cast" might not be clear.

The 8472: "cast" is okay, but we need decent documentation.

Amanieu: So, just keep existing names?

Mara: +1

No objections.

Amanieu to reply.

### (nominated) rust.tf/135811 *Make Miri aware of leaks of \`Box\`/\`Vec\`/\`String\`*

TC: The mentioned `miri_static_root` is a bit underdocumented. Here's a result from some code:

#[cfg(miri)]
extern "Rust" {
    /// Miri-provided extern function to mark the block `ptr` points to as a "root"
    /// for some static memory. This memory and everything reachable by it is not
    /// considered leaking even if it still exists when the program terminates.
    ///
    /// `ptr` has to point to the beginning of an allocated block.
    fn miri_static_root(ptr: *const u8);
}

From:

https://github.com/matthieu-m/static-rc/blob/81d238f5a243f5345aa68b1235860ca372b77499/src/lift.rs#L206

TC: Agreed with Amanieu that there are uses for `leak` that don't "really" leak the value, and so it'd be strange to couple these.

The8472: That it doesn't return a `'static` lifetime is a good argument here for this to not "really" hint it as leaked.

Amanieu: I'll FCP close.

### (waiting on team) rust.tf/134340 *Stabilize \`num\_midpoint\_signed\` feature*

This is just waiting on checkboxes.

### (new change proposal) rust.tf/libs532 *ACP: Expose algebraic floating point intrinsics*

Calder was able to join us for this discussion.

We all thought this made sense, and that there may be other operations for which this also makes sense.

We're going to accept the ACP for the proposed functions and for any other `algebraic_*` functions for which this could make sense (e.g. `mul_add`), which can be worked out in PRs.

In terms of what guarantees we should make, we can also work that out exactly in the PRs, but we in particular noted RalfJ's proposed (non-)guarantee:

> The docs for these methods should make it clear that we are not fixing the exact set of optimizations that can be performed. Basically, the semantic guarantee for these operations is just that they return some float value, and even with the same inputs the resulting float value can be different even within a single program run. Unsafe code cannot rely on any property of the return value for soundness. However, implementations will generally do their best to pick a reasonable tradeoff between performance and accuracy for the result.

TC: I'll reply with the details of the acceptance. Now here:

https://github.com/rust-lang/libs-team/issues/532#issuecomment-2634788605

### (new change proposal) rust.tf/libs531 *Allow unguarded access to an RwLock's inner value using unsafe*

David: ACP asks for `-> &T`. Counterproposal: `-> *mut T`. Expose a subset of the inner `UnsafeCell`'s API on the higher level synchronization types

Amanieu: Yes. In parking_lot, this is called `data_ptr()`

8472: Same thing on other types: `Mutex`, `OnceLock`, ??

Amanieu: Wouldn't `UniqueArc` be a better solution to this problem?

Amanieu to respond.

### (new change proposal) rust.tf/libs530 *ACP: Expose more Unicode casing data in libcore*

Amanieu replied asking for more details. We were inclined to accept at least the base.

### (new change proposal) rust.tf/libs529 *ACP: Add future::ok and future::err*

Nominated for WG-async.

### (new change proposal) rust.tf/libs528 *ACP: Extending \`Borrow\` and \`BorrowMut\` to owned references*

We asked for examples and clarification.

### (new change proposal) rust.tf/libs527 *Introduce a \`Compare\` trait in the cmp mod*

We're sympathetic, but also curious to see the design worked out more fully, particularly in terms of how the standard library would use these traits, and compared to alternatives.

The 8472 to reply.

### (new change proposal) rust.tf/libs526 *ACP: add \`{integer}::unchecked\_div\` and \`{integer}::unchecked\_rem\`*

// SAFETY: obviously not zero
let divisor = unsafe { NonZero::new_unchecked(1) };
// SAFETY: not -1
let result = unsafe { 100.unchecked_div(divisor) };

// SAFETY: not -1 and not zero
let result = unsafe { 100.unchecked_div(1) };

We'll pick this back up later.

### (new change proposal) rust.tf/libs525 *Vec::try\_remove*

### (new change proposal) rust.tf/libs523 *Add a deterministic constructor for \`RandomState\`*

### (new change proposal) rust.tf/libs520 *Add out of the box support for mapping custom error types that implement \`std::error::Error\` to \`Box\<dyn Error\>\`*

### (stalled change proposal) rust.tf/libs207 *\`parse\_line\` method for \`Stdin\`*

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

### (stalled change proposal) rust.tf/libs314 *Add security\_attributes() to windows::OpenOptionsExt*

### (stalled change proposal) rust.tf/libs204 *Integer Manipulation API*

### (stalled change proposal) rust.tf/libs210 *Add associated consts to f32, f64 for mathematical constants*

### (stalled change proposal) rust.tf/libs350 *std::slice::from\_raw\_parts alternative that would accept a null pointer if len == 0 by returning an empty slice*

### (stalled change proposal) rust.tf/libs253 *Provide way to deconstruct std::iter::Rev*

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

### (stalled change proposal) rust.tf/libs357 *ACP: \`std::collections::{hash\_map, btree\_map}::Entry::{is\_vacant, is\_occupied}\`*

### (stalled change proposal) rust.tf/libs366 *Implementing UnixSocketExt traits for solaris/illumos ; starting with the unix\_socket\_exclbind feature*

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