# Libs-API Meeting 2023-10-17

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/52331 *Correcting Path::components on Redox* - (5 checkboxes left)
- merge rust.tf/82901 *Tracking Issue for \`Option::get\_or\_insert\_default\`* - (2 checkboxes left)
- merge rust.tf/83871 *Tracking Issue for CharIndices::offset function* - (3 checkboxes left)
- merge rust.tf/99262 *Tracking Issue for \`io\_error\_downcast\`* - (4 checkboxes left)
- merge rust.tf/106655 *Tracking Issue for \`#!\[feature(offset\_of)\]\`* - (0 checkboxes left)
- merge rust.tf/62726 *Tracking issue for io\_slice\_advance* - (3 checkboxes left)
- merge rust.tf/111922 *feat: implement \`DoubleEndedSearcher\` for \`CharArray\[Ref\]Searcher\`* - (3 checkboxes left)
- merge rust.tf/80552 *Tracking Issue for the GroupBy and GroupByMut iterators* - (3 checkboxes left)
- merge rust.tf/114986 *FCP process: Require 2/3 majority for FCP* - (2 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (1 checkboxes left)
- merge rust.tf/76118 *Tracking Issue for \`array\_methods\`* - (3 checkboxes left)
- merge rust.tf/109402 *Implement owned ops for \`HashSet\` and \`BTreeSet\`* - (4 checkboxes left)
- merge rust.tf/116113 * Generalize \`{Rc,Arc}::make\_mut()\` to unsized types.* - (4 checkboxes left)
- merge rust.tf/69821 *Tracking Issue for const \`mem::discriminant\`* - (5 checkboxes left)
- merge rust.tf/113833 *\`std::error::Error\` \-\> Trait Implementations: lifetimes consistency improvement* - (3 checkboxes left)
- merge rust.tf/116218 *Stabilize \`const\_maybe\_uninit\_zeroed\` and \`const\_mem\_zeroed\`* - (6 checkboxes left)
- merge rust.tf/115974 *Split core's PanicInfo and std's PanicInfo* - (3 checkboxes left)
- merge rust.tf/101288 *Tracking Issue for \`{char, u8}::is\_ascii\_octdigit\`* - (3 checkboxes left)
- merge rust.tf/116485 *Stabilize Ratified RISC\-V Target Features* - (4 checkboxes left)
- merge rust.tf/101196 *Tracking Issue for \`Ready::into\_inner()\`* - (3 checkboxes left)
- merge rust.tf/116570 *Handle out of memory errors in io:Read::read\_to\_end()* - (2 checkboxes left)

[tmandry (2)](https://rfcbot.rs/fcp/tmandry), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [pnkfelix (4)](https://rfcbot.rs/fcp/pnkfelix), [m-ou-se (15)](https://rfcbot.rs/fcp/m-ou-se), [dtolnay (4)](https://rfcbot.rs/fcp/dtolnay), [nikomatsakis (4)](https://rfcbot.rs/fcp/nikomatsakis), [BurntSushi (7)](https://rfcbot.rs/fcp/BurntSushi), [Amanieu (14)](https://rfcbot.rs/fcp/Amanieu), [joshtriplett (13)](https://rfcbot.rs/fcp/joshtriplett), [yaahc (3)](https://rfcbot.rs/fcp/yaahc)

### (nominated) rust.tf/96979 *Override \`Waker::clone\_from\` to avoid cloning \`Waker\`s unnecessarily*

Seems correct, but would be nice if an expert on Waker looks at this.

Missing motivation. Is there real world code that benefits?

Commented.

Happy if wg-async is happy.

Note: Tracking issue not needed for insta-stable clone_from.

### (nominated) rust.tf/116129 *Rewrite \`pin\` module documentation to clarify usage and invariants*

Assigned to amanieu.

Improvement over what we had before. We can keep improving incrementally.

### (waiting on team) rust.tf/114149 *\`read\_dir\` has unexpected behavior for \`""\`*

Currently in FCP to close.

### (waiting on team) rust.tf/116118 *Implement \`Try\` for \`()\`*

Mara commented on the ACP: https://github.com/rust-lang/libs-team/issues/187#issuecomment-1766477359

To close next week.

### (new change proposal) rust.tf/libs275 *\`swap\_retain\` on \`Vec\`*

Mara: retain() is more efficient than repeated remove(), but swap_retain() wouldn't be more efficient than repeated swap_remove(), right?

The 8472: Just a constant factor improvement.

pub fn backward(v: &mut Vec<i32>, c: i32) {
    for i in (0..v.len()).rev() {
        if v[i] == c {
            v.swap_remove(i);
        }
    }
}

pub fn forward(v: &mut Vec<i32>, c: i32) {
    let mut i = 0;
    while i < v.len() {
        if v[i] == c {
            v.swap_remove(i);
        } else {
            i += 1;
        }
    }
}

Amanieu: Seems fine to add this.

Maybe this should be `retain_unstable`

Amanieu: Should we accept, and defer that until stabilization?

The 8472: It should have a 'range' argument.

David: That's filter-drain?

The 8472: That returns an iterator. This one doesn't.

Mara: Seems fine to add this.

Josh: As 'retain_unstable'?

David: I prefer `retain_unstable`. Extends better to other APIs where the same lack of guarantee is worth having: `drain_filter_unstable` is easier to interpret than `swap_drain_filter`

Amanieu: +1, ship it.

Amanieu to reply.

### (new change proposal) rust.tf/libs277 *\[ACP\] RangeBounds::overlaps*

Do we need something that returns something more useful? That returns the intersection?

Mara: Return type of intersection? E.g. two half open ranges always result in a half open range.

Amanieu: Should this be on the trait, or on the range types? The idea being that you'll probably always deal with just one range type.

Amanieu: I'd prefer .union and .intersection on the Range type(s).

David: How about that, but also a .overlaps on the trait?

Amanieu: Need stronger use cases before checking fcp box.

Mara: Same.

David: Open question is interesting. two ranges might intersect/overlap even though there are no elements in the intersection. Example: `StepBy2(2, 8).overlaps(&StepBy2(3, 7))`

Amanieu: This is clearer when we just add methods on the types.

Mara: Yeah, that avoids the problem entirely. (We don't have a type for an Excluded-Excluded range.)

Mara: use cases for the generic one?

David: e.g. get_mut checking if two ranges overlap.

Mara: Right, but then you want the ranges in the open question to not overlap.

Mara: In an impl of get_mut, you'd immediately convert to Range, and then you can do operations on that Range.

Amanieu: use cases are missing on the ACP. I have use cases for similar methods on Range, but not for the generic one on the trait.

The 8472: Accepting `..x` and `x..` for maps etc. you might need this.

Amanieu to reply.

### (new change proposal) rust.tf/libs278 *ACP Implement \`fmt::Write\` wrapper for \`&mut \[u8\]\` (and maybe \`&mut str\`?)*

This is just '`std::fmt::Cursor`', like `std::io::Cursor`?

Amanieu: Does this need to be in the standard library?

Mara: I think so, because now fmt::Write is not implemented for anything useful in no-std code.

It's mentioned as an alternative, that `core::fmt::Cursor` might be the wrong name/path.

Mara: Do we just need an ArrayVec type in core?

Amanieu: that doesn't solve this. you want to write into a specific buffer.

Amanieu: oh actually, ArrayVec/ArrayString seems fine for their use case.

Mara: yeah, but we should have that in core.

Amanieu: yeah, but that's a separate discussion.

Mara left a comment asking about ArrayString.

Amanieu: let's wait for a reply.

### (new change proposal) rust.tf/libs280 *\[ACP\] Provide an interface for creating and modifying instances of fmt::Formatter*

We don't want something that *modifies* a formatter, but we do want something that *creates* a formatter (with your own settings).

Mara to reply.

### (new change proposal) rust.tf/libs281 *Add Seek::seek\_relative*

We have BufReader::seek_relative, but that's not available through the Seek trait.

Implementation: https://github.com/rust-lang/rust/pull/116750/files

Mara: Seems fine?

See https://doc.rust-lang.org/stable/std/io/struct.BufReader.html#method.seek_relative for motivation.

Amanieu: sounds good to me.

Mara replied.

### (stalled change proposal) rust.tf/libs163 *array: add unsafe methods to convert slices to array references*

David: better in `core::array` next to `from_ref` etc. Easier to call than awkward `<&[T; N]>::` syntax.

Mara: Why not try_into().unwrap_unchecked() ?

Amanieu: Good question.

Mara: Also as `core::array::from_slice`, i'd expect this to be safe and return an Option.

Amanieu: That's just try_into.

Mara: Yeah, but easier to write, and could be const.

Amanieu: do we do this in other places, not having an unchecked method because unwrap_unchecked is an option?

Mara: Don't think so, because unwrap_unchecked is quite new.

Amanieu: The ACP has no discussion of TryInto, so let's ask about that.

Mara replied.

### (stalled change proposal) rust.tf/libs156 *&mut \[MaybeUninit\<T\>\]: Fill with value or with closure.*

Mara: Seems fine to me.

The 8472: What's the use over just regular slice fill?

Mara: Getting the initialized &[T] out is useful. might be a subslice of a larger &[MaybeUninit]

Amanieu: Some use cases might need to stop early.

The 8472: It could take an iterator.

Mara: Oh yes, that'd be cool.

Amanieu: We're missing the iterator version of slice fill though.

Mara: We could have fill_from for iterator (next to fill_with for functions).

The 8472: We could 'overload' fill_from by using a trait

Amanieu: that'd break things, probably. separate function seems fine.

Amanieu: Drop write prefix, fill is clear enough (instead of write_fill).

Mara: Agreed

Amanieu: Where would we have these methods?

The 8472: As a non-self taking method on MaybeUninit.

Summary: fill and fill_with is fine, we might also want fill_from on both slices and MaybeUninit.

Mara replied and closed.

### (stalled change proposal) rust.tf/libs155 *Arbitrary alternate flags in \`std::fmt::Formatter\`*

Mara: Noo.

Mara: This doesn't result in very readable code, with custom flags etc. I very much prefer wrapper types. Clearer, and results in better compiled code.

Mara to reply.

### (stalled change proposal) rust.tf/libs124 *Integrate \`Error\` trait with panic interfaces*

Amanieu and Mara to investigate panic mechanism redesign tomorrow.

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

Mara: Might be useful to have a combined lang+libs meeting to discuss where this and related features might go in the future.

### rust.tf/libs251 Expose add/sub/sub_ptr on NonNull

+1

Amanieu to reply.

### ACP: std::ffi::c and std::ffi::os submodules rust.tf/libs134

David: Do we want to keep accumulating types in ffi or sort them into submodules?

Mara: I prefer the current situation over long paths like std::ffi::c::CStr

Amanieu: we'd have std::ffi::c_str, etc.

David: We'd keep CStr in ffi, but we'd have Bytes and errors in the c_str module.

Mara: sgtm. as c_str or cstr

The 8472: probably best to add modules early, because of our process we tend to grow things slowly bigger.

Mara: std::str is big. c_str might also become big.

Amanieu: objection withdrawed. go for it.

David: CString and CStr in separate modules? I think no, because Path and PathBuf go in `path` both

Amanieu: Indeed, same module.

David to reply that c_str is approved.

### rust.tf/libs250 Add LinkedList::{retain,retain_mut}

Mara: retain (as mut) only

+1