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), dtolnay (3), spastorino (1), scottmcm (1), joshtriplett (9), m-ou-se (11), BurntSushi (15), jackh726 (1), nikomatsakis (2), the8472 (1), Amanieu (10), thomcc (1)

(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 selects. 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