# Libs-API Meeting 2023-12-19

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

17 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/117905 *revert stabilization of const\_intrinsic\_copy* - (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/101288 *Tracking Issue for \`{char, u8}::is\_ascii\_octdigit\`* - (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)

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

### (nominated) rust.tf/101196 *Tracking Issue for \`Ready::into\_inner()\`*

8472: prefer to have just `take()` which returns Option, not a panicking `unwrap`

Amanieu: `into_inner`, but should return an Option

8472: if you are in a codepath where you know the Ready has never been polled, you shouldn't have made a Ready in the first place, you should be passing around the original T directly

Josh/David: interested in real-world code that uses this

David: would we make progress if we had real call sites to look at? None of us reliably understand the use case, even after looking at the original implementation PR and Zulip conversation

Amanieu: maybe

David to reply

### (nominated) rust.tf/115386 *PartialEq: handle longer transitive chains*

### (nominated) rust.tf/118108 *PartialOrd: transitivity and duality are required only if the corresponding impls exist*

### (nominated) rust.tf/118799 *Stabilize single\-field offset\_of*

Josh: there was an FCP with all 5 checkboxes, and only a blocking concern about syntax in the multi-field case. No concern of stabilizing single field case

Amanieu: let me just start a new FCP for stabilizing the single field case

8472: there is no guarantee that whatever syntax we later choose for the multi-field case is a superset of this current single field case; might end up maintaining 2 syntaxes in the future, sadly

### (nominated) rust.tf/119026 *std::net::bind using \-1 for openbsd which in turn sets it to somaxconn.*

Amanieu: this PR makes no difference?

Amanieu: SOMAXCONN is 128 everywhere except 4096 on linux, 32 on haiku

Josh: there are a few platforms on which SOMAXCONN is != 128, and the idea is that on those platforms, using SOMAXCONN would be more correct than using hardcoded 128. The few platforms using -1 are using -1 to mean maxint, and the platform clamps that to the correct maxconn value

Amanieu: we should accept

### (waiting on team) rust.tf/118087 *Add Ref/RefMut try\_map method*

waiting on author

### (new change proposal) rust.tf/libs310 *Add \`array::repeat\` for making an array from a non\-\`Copy\` non\-\`const\` value*

8472: multiclone API in the Clone trait would be more efficient than array::repeat for Arc, which could atomically increment the refcount by N instead of N times by 1. Also for locks, which could first make an unlocked clone, release the lock, then do the rest of the clones from that one

Josh: does the possibility of doing multiclone later preclude doing array::repeat now, for usability as opposed to performance? If someone later makes a case for Arc multiclone performance being critical, they can propose multiclone separately and array::repeat can change to use it

8472: Duplicate API, people could just call multi_clone directly.

Amanieu: additional complexity of multiclone does not seem worthwhile, especially if proposing distinct multiclone and multiclone_consuming, which has doubled the API surface

Josh: I can see multiclone come up for types *containing* an Arc, but multiclone of an Arc itself seems less directly useful

8472: I have use cases for multiclone of an Arc specifically. Lots of async code deals with Arcs directly

Amanieu: how about building multiclone into Arc's API, instead of into Clone?

Amanieu: the original motivation was CancellationToken, which is a struct containing Arc

Amanieu: regarding optimizing multiclone, I would rather see that happen at the compiler level rather than with a new lirbary API. Compilers could theoretically optimize multiple clones of Arc into a single atomic increment

Amanieu: I am in favor of array::repeat

8472: compiler automatically optimizing multiclone for Arc is not something we can rely on, extremely complicated

Amanieu: important question is whether the performance gain from optimizing Arc multiclone singlehandedly justifies the complexity of building a new extension point into the Clone trait

Josh: more pressing question is whether the cost of duplicate APIs (if we ever do multiclone later) is so bad that we should block doing array::repeat now. People who just want repeat don't have to wait for us to negotiate the intricacies of multiclone (interaction with derive, etc)

8472: currently there is no way for users to work around doing multiple Arc clones efficiently themselves, without us providing some new mechanism in the standard library

Amanieu: the original motivation from Jake in Zulip was to save a single atomic reference count increment (do N-1 increments instead of N increments). But we can do better, save *all but 1* of the increments

Amanieu to comment

### (new change proposal) rust.tf/libs311 *ACP: Pattern methods for \`OsStr\` without \`OsStr\` patterns*

### (new change proposal) rust.tf/libs314 *Add security\_attributes() to windows::OpenOptionsExt*

### (new change proposal) rust.tf/libs315 *Add \`hint::assume\`*

Ralf suggested `assert_unchecked` for symmetry with `unreachable_unchecked`, `add_unchecked` etc

Do we want `assume_unchecked`, or `assert_unchecked`?

8472: `_unchecked` methods always have a companion with is checked, and in that case that is `assert`

Josh: The primary point of `assert` is to check something, so `assert_unchecked` feels self-contradictory, "check_unchecked, check without the check".

Josh: do we have consensus that we want this API and are just bikeshedding the name?

All: yes

Amanieu: preference for `assume_unchecked` because "assume" is widely what this functionality is known as

8472: only for someone familiar with LLVM

(end of meeting)

### (new change proposal) rust.tf/libs316 *Add nearly in\-place case change methods to String*

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

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