# Libs-API Meeting 2023-11-07

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: David, 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/105135 *Tracking Issue for \`file\_create\_new\`* - (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/113833 *\`std::error::Error\` \-\> Trait Implementations: lifetimes consistency improvement* - (3 checkboxes left)
- merge rust.tf/115974 *Split core's PanicInfo and std's PanicInfo* - (3 checkboxes left)
- merge rust.tf/93610 *Tracking Issue for \`arc\_unwrap\_or\_clone\`* - (3 checkboxes left)
- merge rust.tf/117138 *Add T: ?Sized to \`RwLockReadGuard\` and \`RwLockWriteGuard\`'s Debug impls.* - (3 checkboxes left)
- merge rust.tf/101288 *Tracking Issue for \`{char, u8}::is\_ascii\_octdigit\`* - (3 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)
- merge rust.tf/117468 *Stabilize Wasm relaxed SIMD* - (6 checkboxes left)

[BurntSushi (9)](https://rfcbot.rs/fcp/BurntSushi), [joshtriplett (12)](https://rfcbot.rs/fcp/joshtriplett), [Amanieu (15)](https://rfcbot.rs/fcp/Amanieu), [m-ou-se (9)](https://rfcbot.rs/fcp/m-ou-se), [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay)

### (nominated) rust.tf/rfc3430 *RFC: Unix socket ancillary data v2*

Mara: I've asked Maarten (de-vri-es) to review this. He left a review yesterday.

Josh nominated it, but isn't present in the meeting.

David: Not sure why it is nominated.

The 8472: For attention, since it had been sitting for a while.

Last time: _"Josh to respond on ACP and mark RFC as libs-api nominated so we revisit regularly alongside ACPs"_

Not actionable today.

### (waiting on team) rust.tf/113620 *std windows ERROR\_BAD\_COMMAND could match ErrorKind::InvalidInput.*

The 8472: Does this make sense to do if it is only some project using this code for this?

Chris: Yeah, see comment

Mara: git and php (EIO), ruby and python (EACCES) all map BAD_COMMAND to a different error code than this, which is a rationale against taking heed's mapping (EINVAL)

EINVAL and ERROR_BAD_COMMAND are both 22.

They technically belong to 'different enums', but there's no type system.

David: That they match somewhat seems to be a coincidence.

Mara: Right, [see also EBUSY and CURRENT_DIRECTORY](https://github.com/LMDB/lmdb/blob/3947014aed7ffe39a79991fa7fb5b234da47ad1a/libraries/liblmdb/mdb.c#L1766)

Mara: So, the answer to this PR should be 'no', and we can discuss adding a meaning for ERROR_BAD_COMMAND later when/if someone asks about that.

David: +1

Chris to reply.

### (new change proposal) rust.tf/libs283 *Add \`shallow\_clone()\` method to Cow which always reborrows data*

The 8472: Already discussed. I replied. See https://github.com/rust-lang/libs-team/issues/283#issuecomment-1787089357

2 weeks ago: https://hackmd.io/@rust-libs/B1sENLHG6#new-change-proposal-rusttflibs283-Add-shallow_clone-method-to-Cow-which-always-reborrows-data

David: Mara, you weren't in that meeting.

Mara: *checking...*, yeah i agree.

David to comment and close.

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

We previously said we don't want to be able to modify fmt::Formatter, but want a constructor or builder instead. This is the answer to that.

Mara: Alternative: FormattingOptions that does not contain the &dyn Write. Just the options. Then that is a simple copyable (etc.) type.

David: Mara, can you sketch that out in a comment on the ACP

Mara: Yes. Will do.

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

Mara: Looks reasonable. It's a shame that you have to validate utf8 today when parsing digits or something. Unnecessary.

David: with bytes coming from a CStr or OsStr, yes often you end up parsing

David: the comment from scottmcm is insightful, whether it's clear enough that the input is expected to be `b"127.0.0.1"` vs `[0x7f_u8, 0, 0, 1]`

Mara: This feels right to me, but what are the consequences? Should we have a FromByteStr for every single FromStr impl that we have today?

The 8472: Only for ascii stuff i think. Not for Path for example.

David: Errors might have to do utf-8 validation. You might want different error types.

Mara: Right, but then you can't have a blanket impl.

Mara: Which things should be FromStr but not FromByteStr? Should it always be implemented? It kinda feels like the blanked impl should exist *both* ways, but be overridable. (Which is not how this language works.)

David: We've hit this in other contexts. So we do want the language to support something like this. https://github.com/rust-lang/rust/issues/107460

Mara: Seems like there are two things to discuss on the ACP:
1. What to do if an Error type contains the Vec<u8> or the String?
2. What does it mean for a type to implement FromStr but not FromByteStr?

David:

#[rustc_must_implement_one_of(from_str, from_byte_str)]
pub trait FromStr {
    type Err;

    // you must implement at least 1, but either one
    fn from_str(s: &str) -> Result<Self, Self::Err>;
    fn from_byte_str(bytes: &[u8]) -> Result<Self, Self::Err>;
}

Mara: I like this, but would we extend this over time for from_ascii_str and from_cstr, and so on?

Mara: Do we need a language feature that allows extensibility, like traits do?

David: The difference between str and byte_str is significant, but for ascii or nonzero bytes it doesn't result in the same kind of gains.

David to reply with a counterproposal, and add this to the list in https://github.com/rust-lang/rust/issues/107460

### (new change proposal) rust.tf/libs288 *Closure\-consuming helper functions for \`Debug{Struct,List,Set,Tuple}\`*

Mara: Alternative 1 of a Display/Debug implementing struct wrapping the closure seems way more flexible.

David: But that would require Fn not FnOnce.

Mara: Right. But does that ever matter? I don't think i've ever written a Display impl that consumes anything..

David: Could we generalize .field() etc. to accept closures too?

Mara: Then you can't write `|f|` but will have to write `|f: &mut fmt::Formatter|`, unfortunately.

[The trait solver thinks that you could have implemented Debug for some closure with some different signature]

Mara: This ACP seems fine to me. I can think of many places in std where we can use this to simplify things.

David: How about accepting this and also accepting alternative 1?

Mara: Sounds good, but the wrapper struct should *also* implement Display. (And therefore have different name.)

David: makes sense.

David: I don't mind adding this.

Mara to reply.

### (new change proposal) rust.tf/libs290 *ACP: Move \`std::io::Borrowed{Buf,Cursor}\` into \`core::io\`*

The 8472: Then we might need IoSlice in core. Which is OS specific.
https://github.com/rust-lang/libs-team/issues/104

Mara: We decided that's fine right? Since core can still depend on the target triple.

David: Similar to c_int and c_char etc which vary by libc, not just arch

David: io::Error is not going in core though, so are we committing to not using io::Result in BorrowedBuf?

Mara: We could see BorrowedBuf not as something specific to io, but more generally about byte buffers.. so perhaps it should go in core::buf rather than core::io.

David: there is a Write impl which would need to stay in libstd; if that impl looks at internal fields of BorrowedCursor, we need to make sure it can continue doing its job, but seems fine to me

We can discuss the module name (core::io or something else) later.

Accept.

Mara left a reply.

The 8472 to reply about IoSlice.

### (stalled change proposal) rust.tf/libs131 *Add \`std::fs::rename\_noreplace\`*

### (stalled change proposal) rust.tf/libs164 *Add methods for use cases that \`align\_to\` does not cover*

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

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

### (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)_