---
date: 2025-04-22
url: https://hackmd.io/b-LHRn3RR2qioYyPuiuD7w
---

# Libs-API Meeting 2025-04-22

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, Mara, Josh, David, 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/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)
- merge rust.tf/111137 *Tracking Issue for AVX512 intrinsics* - (3 checkboxes left)

[Amanieu (5)](https://rfcbot.rs/fcp/Amanieu), [nikomatsakis (1)](https://rfcbot.rs/fcp/nikomatsakis), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [BurntSushi (7)](https://rfcbot.rs/fcp/BurntSushi), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [m-ou-se (5)](https://rfcbot.rs/fcp/m-ou-se), [joshtriplett (4)](https://rfcbot.rs/fcp/joshtriplett)

### (nominated) rust.tf/138340 *Remove some unsized tuple impls now that we don't support unsizing tuples anymore*

Seems fine. Crater run happened.

Josh to propose FCP.

### (nominated) rust.tf/139901 *Change proc\_macro::Span::byte\_range \-\> byte\_offset.*

Open question about Range type in return type

Already have this in core: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_ptr_range

Mara: Do we need to block this on figuring out what the new range types will do?

JoshT: Can we stabilize the new range types? Before we do the language change?

Amanieu: They don't bring enough value on their own, without the language change.

JoshT: We could stabilize them if we're confident enough about stabilizing them.

Mara: I don't think we're at that point yet.

TC: There are some open concerns about the new Range types. Lang was generally on board.

Mara: Is there a migration plan for Range as return type?

TC: It's been awhile. I don't recall offhand. There were a number of items to work through.

David: Can we stabilize it with the new range type, without stabilizing the type? Only stabilize the field names? Then we can swap it out for a different type later.

David: Risk could be a Copy impl, which the current Range type does not have.

Amanieu: That kind of defeats the point..

{discussion on some more trait ideas}

Mara: Seems like a lot of hacks for a very simple function

Amanieu: or just bite the bullet and use the old Range type.

Mara: Options:

1. Stabilize with old Range type
2. Stabilize with new Range type without stablizing that type
3. Stabilize with new Range type and stabilize that too
4. Stabilize different API without Range (e.g. byte_offset, or byte_range -> (usize, usize))
5. Don't stabilize byte_range at all for now. (but do stabilize file and local_file)

Amanieu: prefer 3.

JoshT: Prefer 3; if we can't get consensus on 3 then 4. Also fine with 5; `byte_range` should not be a blocker.

Mara: I think 5 is fine.

David: I like 1 and 3. Not worried about 1. We can figure out how to fix that over an edition later. I think the old Range type will be ubiquitous for a while.

David: 5 is fine.

Mara: Happy to go with 5 for now.

### (nominated) rust.tf/139903 *Naming of proc\_macro::Span::local\_file()*

Amanieu: couldn't think of anything better

Josh: `file_no_remap`? To say what it actually is?

Mara: `file()` is also things like "<command line>"

JoshT: Is `file()` already stable? Why is it a String?

Mara: Because it's for display, not for file operations.

Josh: :+1: for `local_file()`.

Amanieu: burntsushi suggested 'path' and 'local_path', but line+column+file is convention.

Amanieu: ship it.

Mara to continue with current names and propose FCP.

### (nominated) rust.tf/139994 *\`impl Display for CStr{,ing}\`*

Mara: Should be a .display() method rather than a direct Display impl?

Amanieu: Mentioned in the motivation in the ACP

> I think that we should not repeat this solution for CStr. The Path type carries with it the intent that you are being careful with your paths and that you want to avoid accidentally breaking a path by round-tripping it through the String type. The CStr type does not carry the same intent with it, and implementing Display is more convenient because it lets you print with the "{name}" syntax instead of having to do "{}", name.display().

Amanieu: Same argument applies to OsStr.

David: Argument is that with OsStr and Path you are using it to be careful with non-utf8 data. With CStr, that's not the same situation. You're using it because you want a thin ptr or ffi'ing with C. Not necessarily because you care about encoding

Mara: What if we have formatting for cstr or byte strings in the future?

David: Could be two methods on Display.

Mara: I'm not happy with Display directly on CStr. .display() is fine.

David: Also fine

The 8472: In the kernel they already use .display() from an extension trait on CStr.

Mara: stdout is just raw bytes. wouldn't expect println!("{cstr}") to replace non-utf8 with replacement characters. wouldn't want that to suddenly change if we ever support byte-str formatting..

Amanieu: I think if we do this for CStr, we should do it for OsStr and Path.

JoshT: +1, but david had an argument against that.

Amanieu: OsStr has just as much chance at having non-utf8 as CStr. You're using this type because the API gave you this. In practice almost always UTF-8.

The 8472: Paths get converted to CStr when doing any OS API calls.

Mara: If i make a program that just calls some C API and prints the results, it shouldn't be lossy

Amanieu: I'm happy with doing it for CStr+OsStr+Path or none. happy with .display()

Mara: Sounds like we have no consensus on Display, but do have consensus on .display()

Mara: implementing Display will automatically give .to_string(). wouldn't be consistent with .to_str() that already exists on CStr.

TC: Josh, what's the history on `CStr` in terms of our UTF-8 expectations there? We could imagine having orthogonally represented the question of "how is the string terminated" and "is there an expectation of UTF-8?".

JoshT: It's in the ffi mod, primarily for ffi purposes.

TC: Just like `Wrapping<T>` or `NonNull<T>`, could we have `Unicode<T>` or `Utf8<T>` or something?

JoshT: `Utf8<T>` maybe shouldn't enforce utf8. Should accept non-utf8, just print with best effort.

TC: In that world, I'd expect `Utf8<T>` to be enforcing, but we could of course have `MaybeUtf8<T>` or whatnot.

JoshT: Anyway, for the current ACP: no consensus on Display, we'll get .display().

---

(Later on...)

The 8472: Could we use `ByteStr` as the `MaybeUtf8` type?

JoshT: The first question is whether we'd want to rule out `CStr` becoming thin. If we did, then we could ask whether `CStr` could deref to `ByteStr`, as then we'd get the searching methods and whatnot.

The 8472: I'll write out a comment.

### (waiting on team) rust.tf/136687 *Improve the documentation of \`Display\` and \`FromStr\`, and their interactions*

### (waiting on team) rust.tf/139865 *Stabilize proc\_macro::Span::{start,end,line,column}.*

In FCP. Removed label.

### (new change proposal) rust.tf/libs576 *Add \`Chars::single(&self) \-\> Option\<char\>\` for getting exactly one character*

We discussed, and were in favor of upstreaming `exactly_one` from itertools:

https://docs.rs/itertools/latest/itertools/trait.Itertools.html#method.exactly_one

The details of that can be hashed out in a separate ACP.

Before we stabilize it, we'd probably want to first stabilize, on the lang side, supertrait item shadowing.

https://github.com/rust-lang/rust/issues/89151

The RFC for that was accepted, and there's a nightly implementation. This now needs documentation and a stabilization report.

### (new change proposal) rust.tf/libs575 *ACP: \`Option::update\_or\_default\`*

### (new change proposal) rust.tf/libs574 *ACP: str::advance\_char*

### (new change proposal) rust.tf/libs573 *ACP: \[perf\] \`proc\-macro\` \`Ident\` should have method \`as\_str\`*

### (new change proposal) rust.tf/libs572 *Add \`Cell::get\` for \`Rc\`\-like shallow\-copying types*

### (new change proposal) rust.tf/libs570 *actually checked bitshifts*

### (new change proposal) rust.tf/libs569 *ACP: abstract \`BufReader::peek\`*

### (new change proposal) rust.tf/libs568 *Implement \`Read\` and \`Write\` traits for \`BorrowedFd\` and \`OwnedFd\`*

### (new change proposal) rust.tf/libs553 *Add a "shrink\-if\-excessive" API to \`Vec\`*

### (new change proposal) rust.tf/libs552 *Provider\-style API for \`Context\`*

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

We talked about the status of the inherent trait impl RFC: https://github.com/rust-lang/rfcs/pull/2375

That's waiting on someone to update the RFC to use `use` syntax.

We discussed this at length, including options such as adding a common `Write` supertrait.

We discussed whether a subtrait that fixes an associated type of the supertrait can be dyn compatible. It can be:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=e83aadcd24d81e1ef8721826715d80a5

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9b60662c77d0eb8a39946808df23dfeb

We discussed how the type punning of `write!`, in terms of how it calls an inherent `write_fmt` on types, is unfortunate.

There was a proposal for how the `write!` implementation could handle this backward compatibly, in that it could expand to:

{
	use core::fmt::CommonWrite as _;
	w.write_fmt(..)
}

Since this way, if there is an inherent method, it would take precedence.

In the end, we decided to close this ACP in favor of waiting for inherent trait impls.

There's a separate question here about `+=`, and we'd like to see a separate ACP for that.

### Vibe check about `core::io::Error`

Josh: If we can make it work (by keeping the method impls that require allocation in alloc or std), any objections?

Amanieu: There's been a lot of demand for it, let's do it.

8472: Want to make sure it has test coverage. And that the coherence split does not cause too much maintenance complexity.

### (stalled change proposal) rust.tf/libs403 *Add \`RawStatusCode\`*

### (stalled change proposal) rust.tf/libs295 *Create iterator function in std libs: split\_item\_mut()*

### (stalled change proposal) rust.tf/libs395 *\`impl core::str::Pattern for \[&str; N\]\`*

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

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

### (stalled change proposal) rust.tf/libs369 *Implement more \`ExactSizeIterators\` on 64\-bit platforms*

### (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/libs210 *Add associated consts to f32, f64 for mathematical constants*

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

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