---
# System prepended metadata

title: Libs-API Meeting 2024-04-30
tags: [Minutes, Libs Meetings]

---

---
date: 2024-04-30
url: https://hackmd.io/Hdratiy6TW-QfOn3Ah8fFA
---

# Libs-API Meeting 2024-04-30

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

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

## 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/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/102012 *Tracking Issue for \`const\_waker\`* - (3 checkboxes left)
  - merge rust.tf/106943 *Implement DoubleEnded and ExactSize for Take\<Repeat\> and Take\<RepeatWith\>* - (3 checkboxes left)
  - merge rust.tf/113744 *Tracking Issue for \`IpvNAddr::{BITS, to\_bits, from\_bits}\` (\`ip\_bits\`)* - (3 checkboxes left)
  - merge rust.tf/62726 *Tracking issue for io\_slice\_advance* - (3 checkboxes left)
  - merge rust.tf/109402 *Implement owned ops for \`HashSet\` and \`BTreeSet\`* - (3 checkboxes left)
  - merge rust.tf/116113 * Generalize \`{Rc,Arc}::make\_mut()\` to unsized types.* - (3 checkboxes left)
  - merge rust.tf/115974 *Split core's PanicInfo and std's PanicInfo* - (2 checkboxes left)
  - merge rust.tf/117468 *Stabilize Wasm relaxed SIMD* - (4 checkboxes left)
  - merge rust.tf/101196 *Tracking Issue for \`Ready::into\_inner()\`* - (1 checkboxes left)
  - merge rust.tf/119131 *Tracking Issue for \`hint::assert\_unchecked\`* - (2 checkboxes left)
  - merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
  - close rust.tf/56167 *Tracking issue for HashMap::raw\_entry* - (3 checkboxes left)
  - merge rust.tf/113219 *Tracking Issue for \`const\_cstr\_from\_ptr\`* - (5 checkboxes left)
  - merge rust.tf/123168 *Add \`size\_of\` and \`size\_of\_val\` and \`align\_of\` and \`align\_of\_val\` to the prelude* - (1 checkboxes left)
  - merge rust.tf/55132 *Tracking issue for thread::Builder::spawn\_unchecked* - (4 checkboxes left)
  - merge rust.tf/98485 *Tracking Issue for \`AtomicBool::fetch\_not\`* - (3 checkboxes left)

[joshtriplett (14)](https://rfcbot.rs/fcp/joshtriplett), [BurntSushi (10)](https://rfcbot.rs/fcp/BurntSushi), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [Amanieu (7)](https://rfcbot.rs/fcp/Amanieu), [m-ou-se (9)](https://rfcbot.rs/fcp/m-ou-se)

### (nominated) rust.tf/94035 *Tracking Issue for ASCII trim functions on byte slices*

Already in FCP

label removed.

### (nominated) rust.tf/123110 *Rename iter::Iterator::intersperse() to ::separate()*

Waiting on language-level feature, unnominated.

TC: (The possible language feature was discussed in the T-lang call last week.  The next step there is for an RFC to be written.)

### (nominated) rust.tf/124367 *Fix #124275: Implemented Default for Arc\<str\>*

David: counterproposal: `impl<T: ?Sized> Default for Arc<T> where Box<T>: Default` (serde does this for Deserialize for Arc)

Josh: We do have blanket impl for `Arc<T>` with `T: Default`

Mara: reminiscent of `Arc::make_mut` where we are considering adding a clone-into-uninit trait (rust.tf/116113); calls for default-into-uninit?

Consensus: FCP, and ask for `Rc<str>` too.

Josh to reply.

Amanieu: Also for OsStr etc?

Josh: Yes, because Box also has those.

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

Not waiting on our team.

### (waiting on team) rust.tf/122661 *Assert that the first \`assert!\` expression is \`bool\`*

Mara to reply.

### (new change proposal) rust.tf/libs375 *Add new API for annoymous pipe and named fifo*

Mara: is this hard on Windows where a pipe might be async or not, depending on a property of the pipe? Will that get in the way in the future?

The 8472: I don't like the cloexec.

Mara: For all other fds that we open, we just set cloexec right away, right?
    
Josh: Yeah, that's appropriate here as well. E.g. when sending a pipe end to another process.

Amanieu: cloexec should be unset in the child after fork() if you want to keep it open after exec.

The 8472: How about nonblocking? Do we have that for sockets?

The 8472: Ah, we do.

The 8472: I'd prefer splitting this in small parts.

Mara: Fine to do this all at once as unstable, and then stabilize in small parts right?

The 8472: Sure

Josh: Should we accept anonymous pipes but not named pipes and platform specific parts?

Amanieu: I think for the use case the author has, they only need anonymous pipes..

Consensus: Accept the anonymous pipes part, without Linux extension methods. Leave the rest for other ACPs.

### (new change proposal) rust.tf/libs373 *Expose LLVM's \`or disjoint\` instruction on ints*

Scott: [LLVM context]

Amanieu: right now not seeing this be useful in real code, but open to adding it as an unstable intrinsic for people to experiment and demonstrate the value

Amanieu: actually unstable is fine; inclined to accept ACP

8472: if it only ever saves a single instruction that's not much, but if it also enables additional arithmetic simplifications it can be worthwhile

Mara: "bitmerge" sounds.. unclear? Should have 'disjoint' in the name.

Amanieu: Accept with rename to "unchecked_disjoint_or"?

David: "unchecked_disjoint_bitor", to match BitOr::bitor?

+1

Josh to reply.

### (new change proposal) rust.tf/libs370 *ACP: macro for UTF\-16 literals*

Amanieu: do people want a string of wchar_t, or do they want UTF-16? In JNI, strings are UTF-16 even in Unix. Whereas wchar_t is 16-bit on Windows and 32-bit on Unix.

Amanieu: I think UTF-16 is outside the scope of the standard library

Mara: with nul termination, we would need a dedicated type for it like with CStr, but without nul termination, this can work without. (just like b"" is `[u8; _]`)

Josh: in the future we may want additional methods on the UTF-16 strings, and would need a type for that

8472: it seems un-rusty to have a macro that claims it produces UTF-16, but is not type-safe so someone could fudge non-UTF-16 values of the same output type

Mara: just like b"🤷‍♀️" gives UTF8 but not a type that is guaranteed UTF8, w"🤷‍♀️" should give UTF 16, even though the type doesn't guarantee valid UTF16.

Amanieu: not convinced this shouldn't just be a community crate

Mara: If we reject the macro, then that's a lang decision.

Josh: Would we want a separate type for valid UTF16? And nul termination?

Amanieu: I think that's outside the scope of std.

8472: the motivation refers to "Win32 or JNI" which is a very broad topic. I don't think there can be a single type that fulfills both purposes

8472: many APIs have validity requirements so a macro that produces &[u16] (without a type that guarantees the UTF-16 validity) is not so useful

Mara: basically all APIs which take UTF-16 really accept any arbitrary &[u16] (so are actually UCS-2)

Mara: Looks like we have a rough consensus to not wanting utf16 support in std. We can tell the lang team that, and ask them to, given that, figure out whether to add a prefix for u16 arrays for ucs-2 literals.

Scott: if libs says "we're not adding a type and we're not adding `to_utf16_uppercase`", then I'd bet the answer is no to the language feature too

Mara: If someone makes a utf16 crate, they might still want a w"" literal feature to not need a proc macro or something.

Consensus: No library support for utf16 literals. Disinclined (objections raised) to add UTF-16 support for e.g. `[u16; N]` or `&[u16]` either. Lang can make their own decisions with that input.

### (new change proposal) rust.tf/libs372 *ACP: env::home\_dir replacement*

Mara: if we expose only a `user_home_dir` and not the other important dirs provided by some of the 3rd-party homedir crates (`config_dir`, `data_local_dir` https://docs.rs/dirs) then it encourages users to misuse `user_home_dir` for things where a different one of the directories would be more correct

Amanieu: we need to ask for clarification about the use cases when `user_home_dir` really is the right thing to be using

(The meeting ended here.)

### (new change proposal) rust.tf/libs371 *ACP: primitive numeric traits*

### (stalled change proposal) rust.tf/libs202 *Support for non\-blocking and best\-effort zero\-copy \`io::copy\`*

### (stalled change proposal) rust.tf/libs169 *Adding locks disregarding poison*

### (stalled change proposal) rust.tf/libs159 *Provide access to the system's random number generator*

### (stalled change proposal) rust.tf/libs207 *\`parse\_line\` method for \`Stdin\`*

### (stalled change proposal) rust.tf/libs148 *Expose raw std{in,out,err}*

_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_
