# Libs-API Meeting 2023-11-14

###### 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

19 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/114986 *FCP process: Require 2/3 majority for FCP* - (2 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (0 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/101288 *Tracking Issue for \`{char, u8}::is\_ascii\_octdigit\`* - (3 checkboxes left)
- merge rust.tf/116570 *Handle out of memory errors in \`io::Read::read\_to\_end\`* - (1 checkboxes left)
- merge rust.tf/117468 *Stabilize Wasm relaxed SIMD* - (5 checkboxes left)
- merge rust.tf/101196 *Tracking Issue for \`Ready::into\_inner()\`* - (2 checkboxes left)

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

### (nominated) rust.tf/93346 *Tracking Issue for panic\_backtrace\_config*

Configuring backtraces without going through the `RUST_` environment variable that `std` listens to.

Mara: we have 2 environment variables today: `RUST_BACKTRACE` and `RUST_LIB_BACKTRACE`

Amanieu: this ACP is only related to `RUST_BACKTRACE`

Mara: we have `Backtrace::force_capture()` which doesn't listen to the environment variable, but does it still listen to short vs full setting from this ACP?

8472: this affects only the panic hook, not manual calls through Backtrace API

Mara: Short vs full is only about what happens during printing; does not affect capture

Amanieu: strange that the ACP does not propose affecting enabled vs not enabled at all, as that is also tied to environment variables today

Mara: `BacktraceStyle::Off` seems like it gives the wrong impression, if backtrace capture may still happen. How about `BacktraceStyle::Hidden`?

8472: On the other hand this is in `std::panic`, not `std::backtrace`; it makes sense it is relevant to rendering of panic

Amanieu: I like the idea of "hidden" instead of "off"

Mara: if you set this to one of the printing styles other than "off", does that *enable* backtrace capture?

Amanieu: if the style is not explicitly set using set_backtrace_style, it falls back to the current environment variables

Mara: Ah, Off does disable capturing in the default panic hook. So `Off` is fine.

8472: the environment variables are more expressive than this API; the reason for having this API is to avoid Rust code needing to do `set_env` calls to control backtracing, not to avoid the standard library doing `get_env` calls

Mara: looks okay to FCP

Mara: It's a bit weird how setting does the same as setting RUST_BACKTRACE, *except* it doesn't enable Backtrace::capture().

Mara to ask about this on the tracking issue.

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

Last time: Mara asked Maarten to review. Lot of activity in the last week.

Josh: separating send and receive into separate types, while increasing surface area of the API, would simplify the implementation

Josh: let's un-nominate, gives some time for it to evolve under guidance from Maarten, and ask for it to be renominated (via rustbot) for consideration when ready

Josh to reply.

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

Mara posted a counterproposal that we talked about last week; ACP author is on board

8472: what about supporting FormattingOptions construction from the format specifier syntax? `format_options!("-<5")`

Formatter::new vs FormattingOptions.build()?

Josh: take/return by value builder vs `&mut` builder?

let fmt_options = FormatterOptions::new()
    .width(...)
    .alternate(true);
let formatter = Formatter::new(write, fmt_options);

// vs

let mut fmt_options = FormatterOptions::new();
fmt_options
    .width(...)
    .alternate(true);
let formatter = Formatter::new(write, fmt_options);

Mara: it would be unfortunate to have no `Formatter::new` function, though potentially more ergonomic for building via builder

Josh: the question is not `new` vs `build`, it's do you want `new` to have 1 or 2 arguments. We could have `new` with just the writer, and separately a `with_options` to change the options.

David: private fields on FormatterOptions vs struct with entirely public fields (and non-exhaustive)

Mara: the current representation is optimized/packed into 3 words which we would lose if individual fields are exposed, although it's possible we could go with the builder being inefficiently represented while packing it during construction of Formatter

Mara: Continue with this builder pattern, or try a fully public fields approach?

*: Continue with builder.

Josh: not blocking ACP; do want to consider whether the builder should use `&mut self` or `self`, which would be more ergonomic?

Amanieu: happy if we remove `new`, so there's only one way to do things

Mara to reply.

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

David: Counterproposal discussed [last time](https://hackmd.io/5w8pMa58QquNIzXfMQAqSw#new-change-proposal-rusttflibs287-ACP-Add-FromByteStr-trait-with-blanket-impl-FromStr) (from_str and from_byte_str on the same trait) does not work

David: There wouldn't be a way for the default from_byte_str impl to construct the error.

Amanieu: we don't have a byte string type. So this is just 'from bytes'

Josh: the name suggests 'as textual', different than 'from raw binary'

Mara: example from last week: IPv4 addresses. With "from bytes" the caller would expect to pass in 4 octets; "from byte str" they pass in the ASCII string bytes

Mara: What i brought up last week is what it means for a type to be FromStr but not FromByteStr, or the other way around. Should they always both be implemented? Same situation as From and Into?

Amanieu: "byte str" is ambiguous about the encoding; does the naming need to include "ascii" in some form? "from ascii str"

Mara: Ascii yes, but the point is that it's safe to call with non-ascii / ascii extensions like utf8.

Amanieu: What would FromByteStr mean for String?

Josh: It'd check utf-8.

Amanieu: So the input is 'unvalidated utf-8'? Should it be FromUtf8Bytes?

Amanieu: It's unclear what encoding this expects. Would every type document what encoding it expects?

Amanieu: consider implementing individual inherent methods on specific types, like Ipv4Address, instead of a from-byte-str trait

Mara: FromByteStr is basically an optimization for utf-8-validation + FromStr.

Amanieu: In all the examples, the only accepted input is ascii.

the8472, josh: `std::os::unix::net::SocketAddr` should presumably accept a file path

Amanieu: I see clear motivation for wanting efficient conversion from byte string to things like integers; but does it really need to be a trait? The semantics of such a conversion are pretty coupled to the specific output type

Mara: Yes, it should be a trait. I use FromStr often, but too often after utf8 validation which was actually useless (e.g. usize::from_str(str::from_utf8(..))).

Josh: It matters whether we see this as a variation of from_str just for optimization, or a specific semantic thing in its own right (with semantics that might be different than from_str).

Amanieu: Then this should be named 'from utf8 bytes'.
So, not things like bytes that represent a unix socket path (non-utf8).

The 8472: We can't enforce that usage.

Amanieu: It's about intention.

Amanieu: use cases for this being a trait?

Mara: E.g. parsing integers and ip addresses etc. from a file. No need to validate UTF-8 first, because the parsing functions (FromStr impls) don't actually care about things being valid utf-8.

Josh: Yeah, and also command line arguments etc.

Amanieu: leave this to a deserialization lib?

Mara: FromStr::from_str(str::from_utf8()) is a common pattern today, and in many cases inefficient. we should provide an alternative. just a few inherent functions doesn't fix this.

Josh: agreed

The 8472: FromByteStr for OsString, would that accept WTF-8 on windows? Or only utf-8.

Mara: Good question.

The 8472: WTF-8 validation would need to happen anyway.

Mara: On Unix we could accept all bytes though, no validation.

Mara: I think on Unix this should accept all bytes for OsString, but i also see that's not consistent with the idea that this is just an optimization for from_utf8+from_str.

David: Ask for more input?

Josh: In Clap they would probably want something that accepts everything, not just utf8.

Josh leaving a comment about clap.

Josh to leave a comment about the apparent two different roles of this trait.

David: Especially OsString (etc.) are interesting to get an answer to.

### (new change proposal) rust.tf/libs292 *Add an \`unsafe fn\` for creating a ZST*

Mara: transmute(()) stops compiling for non-ZST. this should too

David: doing it at runtime is also an option, like for `chunks`. use case, generics:

if mem::size_of::<T>() == 0 {
    conjure_zst::<T>()
} else {
    // something else
}

Mara: Right, that wouldn't work with transmute(()).

David: The 8472 mentioned zeroed(), which does compile in that example.

David: I prefer allowing that example.

Mara: I think i agree. In all cases i personally needed this, transmute(()) was fine (perhaps preferrable), but i think the example above should work.

Josh: If we didn't already have a way to do this I might wonder if we *should*, but since we already have a way to do this, having a cleaner way to do it with more validation seems like a good idea.

Mara: This might encourage / give validitiy to some terrible hacks.

David: the current approach of *not* having conjure_zst (and a place to document why that operation is unsafe) encourages the misconception that it's fine to wrap zst construction in a safe API

Mara: Right. Agreed. The conjure_zst function should document that you should check what guarantees the ZST gives and whether the type being zero sized is actually a semver guarantee.

David: Now i think the snippet above should *not* compile. The other use cases can continue to use mem::zeroed.

Mara: Fair.

Mara: Currently, the ACP proposes to check at runtime.

David: Let's ask on the issue about the two approaches. My preference is the transmute(()) way, to error at compile time.

Mara: The downside is that you can't express that bound in pure Rust. that would need to be an intrinsic/rustc magic.

David to reply.

### (new change proposal) rust.tf/libs293 *\[ACP\] IO traits in \`core::io\`*

### (new change proposal) rust.tf/libs294 *Add get\_mut\_or\_init and get\_mut\_or\_try\_init for OnceCell*

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