HackMD
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), nikomatsakis (1), scottmcm (1), BurntSushi (7), dtolnay (1), m-ou-se (5), joshtriplett (4)
(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:
- Stabilize with old Range type
- Stabilize with new Range type without stablizing that type
- Stabilize with new Range type and stabilize that too
- Stabilize different API without Range (e.g. byte_offset, or byte_range -> (usize, usize))
- 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:
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
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:
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:
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
