# Libs-API Meeting 2024-07-09

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

14 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/106943 *Implement DoubleEnded and ExactSize for Take\<Repeat\> and Take\<RepeatWith\>* - (3 checkboxes left)
- merge rust.tf/109402 *Implement owned ops for \`HashSet\` and \`BTreeSet\`* - (3 checkboxes left)
- merge rust.tf/101196 *Tracking Issue for \`Ready::into\_inner()\`* - (1 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/55132 *Tracking issue for thread::Builder::spawn\_unchecked* - (3 checkboxes left)
- merge rust.tf/123723 *Make \`std::os::tvos\`, \`std::os::visionos\` and \`std::os::watchos\` public* - (4 checkboxes left)
- merge rust.tf/120141 *Tracking Issue for enum access in offset\_of* - (7 checkboxes left)
- merge rust.tf/120140 *Tracking Issue for nested field access in offset\_of* - (5 checkboxes left)
- close rust.tf/44286 *Tracking issue for HashMap \`OccupiedEntry::{replace\_key, replace\_entry}\`* - (3 checkboxes left)
- merge rust.tf/124941 *Stabilize const \`{integer}::from\_str\_radix\` i.e. \`const\_int\_from\_str\`* - (3 checkboxes left)

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

### (nominated) rust.tf/116237 *Scoped thread implicit join doesn't wait for thread locals to be dropped*

FCP close, as discussed last week

### (nominated) rust.tf/126600 *\`std::process::exit\` is not thread\-safe*

Amanieu to start FCP:
- Add lock to exit
- Get C (and in the meantime, popular libc implementations like glibc and musl) to fix its shit
- Don't use quick_exit/_Exit

### (nominated) rust.tf/127343 *regression: type annotations needed for Box\<\_\>*

Discussion from last week: https://github.com/rust-lang/rust/issues/125319#issuecomment-2203697058

Looks acceptable, as expected.

For the future, we should do crater runs on PRs making "acceptable breakage" changes, and if we don't realize that and get notified of the breakage later, we should revert first and *then* do a PR re-adding the change with a crater run.

David to comment that we consider this acceptable breakage.

### (nominated) rust.tf/127481 *Remove generic lifetime parameter of trait \`Pattern\`*

You could turbofish the stable *methods* that take a Pattern. Those methods are stable, even though the trait is unstable

Amanieu: throw it at crater

### (nominated) rust.tf/rfc3301 *\[RFC\] AtomicPerByte (aka "atomic memcpy")*

API design struggles: https://github.com/rust-lang/rfcs/pull/3301#issuecomment-2206131327

Amanieu to look at it async.

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

Nominated for WG-async. Is there anything we can do?

Eric Holk still working on comprehensive async iteration RFC

### (new change proposal) rust.tf/libs405 *Add \`OnceLock::wait\`*

Mara: Sounds good. +1

Implementation might be tricky. Doesn't fit in today's implementation. Would need a different `Once`.

Amanieu: Regardless of implementation, if this was possible, would we want this API?

Mara: +1

Josh: +1

Josh: Would be nice if we had an async .await version of this as well. (Separate proposal.)

David: Also on Once then?

Amanieu: +1

Mara: +1

Mara replied.

### (new change proposal) rust.tf/libs406 *Make \`proc\_macro\` available outside procedural macro generation*

What would happen on emiting diagnostics from a proc_macro outside proc macro context?

David: Should that just print the message without the span?

Amanieu: i think it should panic

David: TokenStream::expand_expr() wouldn't be able to work. Although that one returns a Result..

Josh: Why would you want to use this in a build script?

David: Bindgen uses it to generate Rust code. Protobuf crates as well.

Internals forum thread about "syn in proc_macro": https://internals.rust-lang.org/t/how-can-we-improve-proc-macro-without-dependencies/19996

Next step: Ask which behaviour they are exactly changing. Not everything is possible outside proc macro context, so somethings will still need to error/panic. Need an overview of what will and won't work.

David: Implementation strategy: One way is to make everything an `enum { Real(..), Fallback(..) }`. Alternative is to keep the 'everything is a handle' implementation and lazily spawn a rustc/host.

Josh: Or a compile time cfg solution.

Mara: That'd need recompiling the entire dep tree (e.g. syn etc.) for using the proc macro in a different context.

David: Could be doable

Josh: David, is there a path where proc_macro2 would no longer duplicate this if we go down this path?

David: Don't think so, proc_macro2 adds more than just this. We backport new APIs and emulate it on old rust versions.

Josh: Handles could be opaque pointers whose meaning depends on whether in compiler context or not.

Amanieu: Or 32 bit indexes that are either compiler handles or an index into a global vec.

David: Yeah that'd work.

Josh to reply.

### (new change proposal) rust.tf/libs407 *Add \`Option::as\_deref\_inner: Option\<&T\> \-\> Option\<&T::Target\> where T: Deref\`*

Mara: So... the `&**` operator.

Mara: Useful for `Option<&String>` to `Option<&str>`.

David: I don't think it has much value, because it only replaces just one call to `map`.

David: Should we have a way to do `&**` more conveniently? I do that all the time. E.g. match with box. Could use .deref().

David: Add Deref trait to prelude in 2024?

Amanieu: as_deref_inner is inscrutable. Not clear. I don't see how you'd go from having this problem to finding this as your solution

Josh: +1. Also don't want to come across this when reading someone's code. Less readable than e.g. `.map(|x| x.as_str())`.

Conclusion: We don't want this because it's not very clear/readable.

Mara replied and closed.

### (new change proposal) rust.tf/libs408 *Adding the contains method for the iterator trait*

Mara: .contains() taking by reference would lead to a double reference in `[].iter().contains(&&1)`.. just `.any()` might be better?

Itertools uses `Borrow+PartialEq` rather than `Item: PartialEq<Q>`.. https://github.com/rust-itertools/itertools/pull/514 Unclear why. Mistake?

David: Probably because of a missing `: ?Sized`.

We would want `&Q` with `Self::Item: PartialEq<Q>` with `Q: ?Sized`.

Mara: Not sure if this provides enough value over `any` with `|| ==`.

Amanieu+Josh: I think it provides enough value

David: Agree with Mara.

Mara: Happy to see it as unstable though, but let's set the right expectations.

Amanieu to reply.

### (new change proposal) rust.tf/libs409 *Add \`BufRead::try\_read\_until\`*

Mara: BufRead::fill_buf is blocking.. so if you want something nonblocking, you should start there?

Amanieu: I don't think it's the BufRead's job to decide if something is blocking. The underlying socket can be blocking or not.

Mara: This ACP is impossible. You cannot implement it in terms of fill_buf+consume, which are the only required methods.

Mara: I guess they might want it on BufReader.

Mara replied.

### (stalled change proposal) rust.tf/libs231 *ACP: Add const fn TypeId::matches for comparing type ids in consts*

We're not closer than last year in having `==` work. So accepted.

Mara replied.

### (stalled change proposal) rust.tf/libs189 *ACP: Implement Step for many PartialOrd types that have good notion of predecessor and successor*

Amanieu: I'd reject all of it

Mara: I'd accept all except Wrapping and Saturating

Josh: Same

https://github.com/rust-lang/libs-team/issues/130 is only for unsigned NonZero

Mara: Accept for NonZero only?

That proposal is only for unsigned..

Step for signed NonZero steps over 0??

David: We do that for char already

Josh: Accept for all NonZero

Amanieu: I'd accept 130, only unsigned.

Josh: Why would you think signed NonZero would be a mistake?

Mara: I also don't think we should have Step on signed.. It's very easy to miss that that would silently skip over the zero.

Conclusion: Accept 130.

Reject this one.

### (stalled change proposal) rust.tf/libs248 *ACP: Add \`finish\_non\_exhaustive\` to \`DebugList\`, \`DebugMap\`, and\`DebugTuple\`*

Seems fine.

Also DebugSet.

Amanieu to reply.

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

### (stalled change proposal) rust.tf/libs261 *add \`write\_fmt\` method to String, to make \`write!\` macro work without imports*

Not interested in `write_fmt` inherent method that returns Result. Not viable to add `write_fmt` inherent method that returns ().

Counterproposal: `+= format_args!(...)`, needs PR and crater run

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