# Libs-API Meeting 2024-01-16

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

18 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/98934 *Add \`Option::take\_if\`* - (3 checkboxes left)
- merge rust.tf/115386 *PartialEq, PartialOrd: update and synchronize handling of transitive chains* - (3 checkboxes left)
- merge rust.tf/113489 *impl \`From\<&\[T; N\]\>\` for \`Cow\<\[T\]\>\`* - (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/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/117468 *Stabilize Wasm relaxed SIMD* - (5 checkboxes left)
- merge rust.tf/101196 *Tracking Issue for \`Ready::into\_inner()\`* - (2 checkboxes left)

[Amanieu (11)](https://rfcbot.rs/fcp/Amanieu), [joshtriplett (13)](https://rfcbot.rs/fcp/joshtriplett), [dtolnay (2)](https://rfcbot.rs/fcp/dtolnay), [BurntSushi (8)](https://rfcbot.rs/fcp/BurntSushi), [m-ou-se (10)](https://rfcbot.rs/fcp/m-ou-se)

### (nominated) rust.tf/libs320 *Libs\-team RFC guidelines appear to be out of date*

Amanieu to follow up.

### (nominated) rust.tf/96710 *Tracking Issue for \`round\_ties\_even\`*

FCP started, unnominating.

### (nominated) rust.tf/99262 *Tracking Issue for \`io\_error\_downcast\`*

Josh: one concern about Box in the signature was related to a push to move io::Error into core, which seemed feasible except for io::Error being able to hold a Box. But it turns out there is Box in several other methods, so we don't need to block adding more.

Amanieu: why can't it return `E` directly as opposed to `Box<E>`?

Mara: that would potentially involve large memcpy

Mara: if in the future we introduce a specialization to avoid double boxing things like String, then downcast would need to needlessly invent a new Box to return Box\<String\>

Amanieu: considering this is all related to an error codepath, double boxing String doesn't seem bad

Josh: Tradeoff seems like: if you wanted it in a box,

Josh: In theory if we're already pulling specialization stunts, we *could* let you call `downcast::<Box<SomeError>>` if you want it boxed.

Mara: Rename to `downcast_box`?

David: I like the downcast::<Box<..>> idea.

Mara: Can we do that? What about `downcast::<Box<Box<Box<..>>>>`

David: We'd store the typeid of the box, not of the E. but that would require storing extra info.

Amanieu: Just returning `E` without Box seems fine, because all other use cases are covered by into_inner, i think

Amanieu: Let's ask to update the docs, remove the Box, and then start the FCP

Mara: Sounds good

Amanieu to reply.

### (nominated) rust.tf/117561 *Stabilize \`slice\_first\_last\_chunk\`*

In FCP.

Do we want to reserve the same names on `[T; N]`?

Talked about that last week: No, don't under the same names.

Removed nominated label.

### (nominated) rust.tf/118580 *Provide a way for custom derives to know if they were invoked via \`#\[derive\_const\]\`*

Mara: As unstable, seems fine.

Amanieu: Needs tracking issue.

Mara: Go ahead as long as we get an FCP for stabilzation?

Mara replied.

### (waiting on team) rust.tf/119550 *Rename \`AsyncIterator\` back to \`Stream\`, introduce an AFIT\-based \`AsyncIterator\` trait*

_"After some offline conversations I'm converting this to a draft PR until we have consensus within WG Async how we want to proceed"_

Mara: Not nominated for us, waiting-on-team is for wg async i think?

### (new change proposal) rust.tf/libs323 *Add \`ptr::fn\_addr\_eq\` to compare functions pointers.*

### (new change proposal) rust.tf/libs325 *Add macro \`static\_assert\` to perform compile\-time assertion checking*

### (new change proposal) rust.tf/libs326 *ACP: Add \`OsStr::display\` (similar to \`Path::display\`)*

Mara: ship it

Josh: yes please

Mara: should there be separate Display *type* for OsStr vs Path? Or reuse the same type

David: related PR https://github.com/rust-lang/rust/pull/112136 adding std::ffi::c_str

Let's put the type in std::ffi::os_str::Display, and make std::path::Display an alias

8472: will path::Display ever need to do different normalization like stripping `..`?

Amanieu: it doesn't cost us much to just have separate Display types

8472: we have enough problems with Path that I don't feel comfortable coupling Path's internals into other types

Amanieu to reply accepting ACP

### (new change proposal) rust.tf/libs327 *Add Wrapping/Saturating::from\_mut reference conversions*

### (new change proposal) rust.tf/libs328 *Add \`Option::merge\`*

Mara: Iterator::reduce?

Amanieu: zip_with?

David: Not zip_with, that is None if either is None.

Josh: Is `merge` any clearer than just a if-let or match?

Mara: Let's ask them why `Iterator::reduce` is not good enough. If that's not good enough, we can re consider.

Mara replied.

### (stalled change proposal) rust.tf/libs120 *ACP: Uplift \`iter::repeat\_n\` from itertools*

Amanieu: seems fine

David/Josh/Mara: looks good

Amanieu: can we make .repeat(x).take(n) more optimal?

Josh: even if so, repeat_n still seems clearer

Related: https://github.com/rust-lang/rust/pull/106943 "Implement DoubleEnded and ExactSize for Take<Repeat> and Take<RepeatWith>"

Josh to reply accepting the ACP

### ACP: Add OsStr::display (similar to Path::display) #326

Amanieu: Fine, with a separate Display type

Mara: Slightly prefer reusing the existing path::Display type with an alias.

David: Name? std::ffi::os_str::Display

David: Prefer making it an alias for std::path::Display

The 8472: We might want path::Display to do something more?

Mara: That should then be a different method on path. Path::display() and OsStr::display() should show the same.

Mara: Separate types also fine.

Amanieu to reply

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