---
date: 2025-05-06
url: https://hackmd.io/az893wfQSMGCrV6Pc4JmgA
---

# Libs-API Meeting 2025-05-06

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, David, Josh Triplett, Mara, The 8472, TC, Sarah Quiñones, martinomburajr

## 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/138498 *Implement Deref\<Target=ByteStr\> for CStr* - (3 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/130823 *Tracking Issue for \`non\_null\_from\_ref\`* - (3 checkboxes left)
- merge rust.tf/122661 *Change the desugaring of \`assert!\` for better error output* - (3 checkboxes left)
- merge rust.tf/137992 *Stabilise \`os\_string\_pathbuf\_leak\`* - (4 checkboxes left)
- merge rust.tf/115585 *Tracking issue for \`cfg\_match\`* - (2 checkboxes left)
- merge rust.tf/138016 *Added \`Clone\` implementation for \`ChunkBy\`* - (3 checkboxes left)
- merge rust.tf/111137 *Tracking Issue for AVX512 intrinsics* - (3 checkboxes left)
- merge rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* - (8 checkboxes left)
- merge rust.tf/129121 *Stabilize \`tcp\_quickack\`* - (3 checkboxes left)
- merge rust.tf/129333 *Tracking Issue for \`lazy\_get\`* - (3 checkboxes left)
- merge rust.tf/138023 *Add \`std::io::Seek\` instance for \`std::io::Take\`* - (3 checkboxes left)
- merge rust.tf/138879 *Ensure non\-empty buffers for large vectored I/O* - (5 checkboxes left)
- merge rust.tf/139916 *make std::intrinsics functions actually be intrinsics* - (3 checkboxes left)
- merge rust.tf/131719 *Tracking Issue for \`const\_eq\_ignore\_ascii\_case\`* - (4 checkboxes left)
- merge rust.tf/137268 *Allow comparisons between \`CStr\`, \`CString\`, and \`Cow\<CStr\>\`.* - (3 checkboxes left)

[compiler-errors (1)](https://rfcbot.rs/fcp/compiler-errors), [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay), [spastorino (1)](https://rfcbot.rs/fcp/spastorino), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [joshtriplett (9)](https://rfcbot.rs/fcp/joshtriplett), [m-ou-se (11)](https://rfcbot.rs/fcp/m-ou-se), [BurntSushi (15)](https://rfcbot.rs/fcp/BurntSushi), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis), [the8472 (1)](https://rfcbot.rs/fcp/the8472), [Amanieu (10)](https://rfcbot.rs/fcp/Amanieu), [thomcc (1)](https://rfcbot.rs/fcp/thomcc)

### (nominated) rust.tf/libs383 *Add \`FRAC\_1\_SQRT\_2PI\` constant*

C and C++ don't have this, but this is a useful constant.

Mara: I'm a big tau fan, but `2pi` makes more sense as this is how most people will know this constant.

ACP accepted for the `2pi` name.

### (nominated) rust.tf/115585 *Tracking issue for \`cfg\_match\`*

JoshT: Open question is if this should be 'exhaustive'.

JoshT: We can't really compute that, but we can require a `_ => {}` case.

TC: Happy with the `cfg_match` name (instead of `cfg_if`), but then we should give it a 'match' flavor.

Amanieu: How can we force exhaustiveness?

TC: Just throw compiler error when it falls through.

JoshT: Proposal was not to require `_ => {}`, but to be noisy when it falls through.

Amanieu: An implicit `_ => compiler_error!()`

JoshT: I'd advocate for 'compiler_warning' instead.

Amanieu: prefer error

The 8472: if some impl is missing, it'd result in an error anyway.

TC: prefer error

Mara: prefer error

JoshT: mildly prefer warning, would not object to error.

Amanieu: another concern was: maybe this should be a language feature?

JoshT: we shouldn't delay this further

Amanieu: how does this interact with the cfg(true)/cfg(false) rfc?

JoshT: we should support that here too. should support the exact same as cfg()

Mara: You'd have `true =>` and `false =>` which is.. eh. we should maybe lint about that.

JoshT: `&&` and `||` seem fine too.

Amanieu: Don't really mind, but it's looking less and less like `match`..

Amanieu: Bevy is using `switch` as the name..

The 8472: `cases`?

Straw poll:

- `cfg_case!`
- Josh: +0.5
- TC: +0.75
- Amanieu: -0.5 (this is exactly like cfg_switch, but with the other C keyword)
- The 8472: +0
- Mara: -0.5
- `cfg_cases!`
- The 8472: +0.75
- Amanieu: -0.5
- Mara: -0.5
- `cfg_cond!`
- TC +1.
- Amanieu: +0.75
- Josh: +0.5
- The 8472: -0
- Mara: -0.5
- `cfg_many!`
- Josh: -0.5 (agree with Mara's objection)
- TC: +0
- Mara: -1 (it picks exactly one, that's the opposite of 'many')
- Amanieu: -0.5
- `cfg_match!`
- Josh: +1
- David: +1
- TC: +0
- The 8472: -0.5
- Amanieu: -0.5
- Mara: +0.5
- `cfg_select!`
- Amanieu: +1
- Josh: +1 (but mild preference for "just ship the `cfg_match!` we have already")
- TC: +0.5
- The 8472: -0.5
- `cfg_cascade!`
- Josh: +0.1
- David: +1
- TC: +0
- The 8472: -0.5
- Amanieu: -0.5
- `cfg_one!`
- Amanieu: -1
- `cfg_first!` (picks the first matching one)
- Amanieu: -1
- The 8472: -1
- `cfg!` (add to existing macro)
- Josh: -0 (would not object)
- Amanieu: -1
- David: +0.5
- Mara: +0.5
- `cfg_if!` (old syntax??)
- Amanieu: +0
- Josh: -1, new syntax is an ergonomic win
- TC: -1
- `cfg_if!` (new syntax)
- Amanieu: +0.5
- TC: -0
- Mara: -0.5, gonna be messy with existing cfg_if in ecosystem
- Josh: -0, annoying for people porting
- `cfgs!`
- Josh: -0.5

Sarah: don't like that cfg_match!() doesn't look like a match: arms are boolean conditions. cfg_if!() looks more like regular rust code.

Amanieu: issue is that `match` is for pattern matching. This has nothing to do with pattern matching.

Mara: I might be more in favor if we wrote `#[cfg(..)] =>` rather than `.. =>`. Clearer that it's the same cfg() syntax.

Sarah: what if we had a `if cfg` block. e.g. `if cfg { any(unix, windows) } { ... } else if cfg { macos } { ... } else { ... }`.

Amanieu: very close to `if cfg!(..)` which is similar but very different.

Sarah: Usually if people write `if cfg!()` they don't want the code to be checked on non-matching platforms.

Sarah: maybe something like `#[cfg_match] if cfg { ... }`

Mara: Attributes on stmts are not yet stable.

Sarah: Close to stabilization, i think

Amanieu: I think it'd be weird for an attribute to change how the language is parsed like that.

JoshT: I think we should be finding a name, not finding a new syntax.

Amanieu: In the future we can easily deprecate the libs feature if there's a language feature to replace it. Like `try!()` and `?`

TC: Back to the syntax bikeshed..

Amanieu: I like `cfg_select` because we are selecting one. `cfg_cond` also fine. Everything else feels random.

TC: I could get behind `cfg_select`. I didn't like this initially for the reasons other people brought up, but I've warmed to it.

JoshT: `match` is a lang feature, but `select` is not. no one will confuse it with the ecosystem `select`s. The 8472: do you object to `select`?

The 8472: Already what tokio uses for futures, for extracting one value. Not a blocking objection though.

TC: Looking at the list above, it seems to come down to `cond` and `select`. Either seems OK. `select` carries some baggage but it is more familiar. `cond` would be new jargon (to Rust) but carries no baggage.

Mara: between those two, `select` is miles better for me: "cond" could mean anything, but "select" is clearer about selecting exactly one case.

Martin: For cond, we have the CondVar type in `std::sync`.

JoshT: Select is a verb. cond, case, etc. are not.

Amanieu: So... consensus on `cfg_select`?

Amanieu: Cancel fcp and restart on new name

TC: Let's include the 'error on no match' in the FCP.

TC: It's pretty bad in expression position. We shouldn't stabilize the `{{}}` syntax; that's weird.

Mara, Josh: Agree on double braces.

JoshT: Happy to stabilize the version for item position first, add expression version later.

JoshT: We should probably apologize as part of the re-FCP. We went from select to match to select.

Mara: Part of the re-fcp was new information: the cfg() syntax RFCs.

TC: For later future work, Sarah raised an interesting point. cfg!() works in static initializer, so is const evaluated. we can pull this into some kind of 'const if' feature.

Sarah: Fine in expression position, but not sure otherwise.

TC: Consensus (proposed) here is that we restart FCP with `cfg_select!` and specifying that:

- If it hits an uncovered case, we trigger a compiler error.
- Removing the double brace expression syntax (we'd prefer it eventually work without that).

We explain to people our updated reasoning, we refile the existing concern about `let`.

TC: Right now it always returns a block. Probably we don't want that. Would we consider it a breaking change to no longer return a block? People could of course tell that in stable code.

Mara: Also because of Rust 2024, a block has different temporary behavior.

Amanieu: I'd be happy to block this until it's turned into a built-in macro.

Josh: Do people have a blocking objection to shipping one that only supports item position?

Mara: That's fine. especially since `{cfg_select!(..)}` just works as expression.

Amanieu: Are we happy requiring the braces on each arm?

Mara: For items, non-braces gets really weird: `_ => struct Item();,` with comma? without comma?

Amanieu: We could have separate macros for items and exprs.

Josh: `cfg_expr!`?

Mara: Let's just ship this aimed at items. We can add more functionality or another macro later.

TC: I'll leave a comment with the outcome here.

### (nominated) rust.tf/129121 *Stabilize \`tcp\_quickack\`*

FCP started.

### (nominated) rust.tf/130703 *Tracking Issue for secure random data generation in \`std\`*

We'll plan to do some design work on this at the all hands.

### (nominated) rust.tf/130994 *Tracking Issue for File lock API*

https://github.com/rust-lang/rust/issues/130994#issuecomment-2849282463

Josh: The new API is not ergonomic.

if file.try_lock()?.not_locked() {
    println!("Waiting for the lock");
    file.lock()?;
}

Amanieu: If you call `try_lock` and it fails to acquire the lock, it shouldn't be returning an `Ok(_)` variant. You could be calling `try_lock` because you want to try once and not block, and then bail on any failure.

TC: We could add a convenience method to `io::Result` that would pull out `WouldBlock`. This would be helpful in other cases (as would such a helper for `Interrupted`).

if file.try_lock().would_block()? {
    // ..
}

Amanieu: Maybe we could make a more general method on `Result`.

Amanieu: Or maybe we could have a method that does:

Result<T, E> -> Result<Result<T, E1>, E2>

file.try_lock().map_or_else(true, |e| if e.kind() == WouldBlock { 
    Ok(false)
} else { 
    Err(e)
})

TC: In terms of a generic method on `Result`, I actually this is the one we'd want, if we wanted one:

if file.try_lock().try_is_err_and(|e| e.kind() == WouldBlock)? {
    // ..
}

Code pattern 1: `try_lock()` and bail on error *or* on lock acquisition failure

Code pattern 2: `try_lock()` and bail on errors *except* lock acquisition failure, handle the lock acquisition failure specifically

Amanieu: In conclusion, we'll return an `io::Result<()>`.

Josh: I'll write it up on the issue.

### (nominated) rust.tf/138879 *Ensure non\-empty buffers for large vectored I/O*

FCP started.

### (nominated) rust.tf/139916 *make std::intrinsics functions actually be intrinsics*

FCP started.

### (nominated) rust.tf/140005 *Set MSG\_NOSIGNAL for UnixStream*

We started the proposed FCP after discussion.

### (nominated) rust.tf/140151 *remove intrinsics::drop\_in\_place*

FCP started.

### (waiting on team) rust.tf/136687 *Improve the documentation of \`Display\` and \`FromStr\`, and their interactions*

To be discussed in all-hands.

### (waiting on team) rust.tf/138023 *Add \`std::io::Seek\` instance for \`std::io::Take\`*

FCP started.

### (new change proposal) rust.tf/libs583 *\`Vec::into\_chunks\` to reverse \`Vec::into\_flattened\`*

Just opened, defer to next week.

### (new change proposal) rust.tf/libs582 *std::fs::set\_symlink\_permissions*

### (new change proposal) rust.tf/libs581 *ACP: Positioned reads into uninitialized buffers (\`FileExt::read\_buf\_at\`, ...)*

### (new change proposal) rust.tf/libs580 *ACP: \`ManuallyDrop\<T\>::pinned\_\*\` methods*

This seems OK. ACP accepted.

### (new change proposal) rust.tf/libs579 *ACP: \`Vec::push\_mut\` and \`Vec::insert\_mut\`*

We already had accepted `Vec::push_mut`. We'll accept `Vec::insert_mut` and track them together.

### (new change proposal) rust.tf/libs578 *ACP: hash\_map! macro to create \`HashMap\`s such as \`vec!\`*

Deferred to next meeting

### (new change proposal) rust.tf/libs577 *Option::try\_get\_or\_insert\_with*

### (new change proposal) rust.tf/libs575 *ACP: \`Option::update\_or\_default\`*

### (new change proposal) rust.tf/libs574 *ACP: str::advance\_char*

### (new change proposal) rust.tf/libs573 *ACP: \[perf\] \`proc\-macro\` \`Ident\` should have method \`as\_str\`*

### (stalled change proposal) rust.tf/libs262 *Add infallible variant of RangeFrom::next()*

### (stalled change proposal) rust.tf/libs295 *Create iterator function in std libs: split\_item\_mut()*

### (stalled change proposal) rust.tf/libs449 *ACP: Chars::take\_str*

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

### (stalled change proposal) rust.tf/libs296 *ACP: Designing an alternative \`FromStr\`*

### (stalled change proposal) rust.tf/libs455 *slice::Windows::as\_slice*

### (stalled change proposal) rust.tf/libs253 *Provide way to deconstruct std::iter::Rev*

### (stalled change proposal) rust.tf/libs348 *std::os::unix::env::{argc, argv}*

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

### (stalled change proposal) rust.tf/libs395 *\`impl core::str::Pattern for \[&str; N\]\`*

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