---
title: "Libs-API Meeting 2024-04-02"
date: 2024-04-02
discussion: https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings/topic/Meeting.202024-04-02
url: https://hackmd.io/sowyNNVyT7a1cuUgDpJvQA
---

# Libs-API Meeting 2024-04-02

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

1 rust-lang/rfcs T-libs-api FCPs

- merge rust.tf/rfc3550 *RFC: New range types for Edition 2024* - (4 checkboxes left)

20 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/98934 *Add \`Option::take\_if\`* - (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/107462 *Implement \`FromIterator\` for \`(impl Default + Extend, impl Default + Extend)\`* - (2 checkboxes left)
- merge rust.tf/113744 *Tracking Issue for \`IpvNAddr::{BITS, to\_bits, from\_bits}\` (\`ip\_bits\`)* - (3 checkboxes left)
- merge rust.tf/99262 *Tracking Issue for \`io\_error\_downcast\`* - (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.* - (4 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\`* - (6 checkboxes left)
- close rust.tf/119799 *Return the delimiter from slice::split\_once* - (4 checkboxes left)

[joshtriplett (16)](https://rfcbot.rs/fcp/joshtriplett), [yaahc (2)](https://rfcbot.rs/fcp/yaahc), [dtolnay (2)](https://rfcbot.rs/fcp/dtolnay), [nikomatsakis (4)](https://rfcbot.rs/fcp/nikomatsakis), [Amanieu (5)](https://rfcbot.rs/fcp/Amanieu), [pnkfelix (3)](https://rfcbot.rs/fcp/pnkfelix), [m-ou-se (14)](https://rfcbot.rs/fcp/m-ou-se), [scottmcm (2)](https://rfcbot.rs/fcp/scottmcm), [tmandry (2)](https://rfcbot.rs/fcp/tmandry), [BurntSushi (11)](https://rfcbot.rs/fcp/BurntSushi)

### (nominated) rust.tf/121920 *downgrade ptr.is\_aligned\_to crate\-private*

FCP finished. Should be merged?
- We need to discuss whether to make crate-private or not.

Mara to reply.

Ralf replied.

..: We don't see a reason to keep this function. It might need a new ACP to convince us to keep it.

David to reply.

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

Mara: Currently, assert expands to `!$expr`, so accepts something that's not bool that has Not resulting in bool.

Mara: Should this be an edition change or just breaking change?

Amanieu: break

Josh: Crater run

Eric Holk: +1

Josh: Don't consider this a stable guarantee. we could have done `== true` or `== false` or any equivalent.

Amanieu: docs clearly say that it expects a bool

Mara to reply and review.

### (nominated) rust.tf/122924 *Replace unstable \`Waker::noop()\` with \`Waker::NOOP\`.*

(The tracking issue: https://github.com/rust-lang/rust/issues/98286)

Eric: No strong opinions in wg-async. Whatever fits best with the rest of the language.

Amanieu: associated consts are preferred.

Amanieu: Drop for a const is weird though

David: Note that the const is a reference to a Waker, not a Waker. so no Drop.

joboet on github:

> I'm strongly opposed to this. Constants are used when we actually care about the specific value in question (so you could e.g. match on it), not just about its semantics. Hence e.g. ONCE_INIT was deprecated in favour of Once::new(). Here, we don't care about the specific vtable or pointer used, and wouldn't care if they changed across calls to Waker::noop, as long as the resulting Waker obeyed the rules outlined by the documentation.

Josh: It is mentioned on the github thread that this might close the door to a `static Waker` to make it have a single address.

..: Can a const reference a static?

Mara: rustc says: error[E0658]: referencing statics in constants is unstable

Mara: You get that error too in a `const fn` though, so that doesn't really close any doors.

Amanieu: I don't see a good use case for `NOOP` itself being a static.

Josh: And we can probably fix the limitation in the language in the future.

(Discussion about whether the constant should be of type `Waker` or `&Waker`.)

TC: We want a reference to a Waker, not the Waker itself, due to considerations around promotion. E.g.:

pub const NOP_CONTEXT: Context<'static> =
    Context::from_waker(&Waker::NOOP);
//~^ ERROR destructor of `Waker` cannot be evaluated at compile-time
//~| NOTE the destructor for this type cannot be evaluated in constants
//~^ ERROR temporary value dropped while borrowed
//~| creates a temporary value which is freed while still in use

TC: If the constant is instead of type `&Waker`, then this works.

Kevin: The use case of the static is to have a unique address for the NOOP waker. If you know that the waker is NOOP, then you don't have to store it anywhere. Bit of a strange case, but it does (rarely) occur.

David: We can do that in the future with this API, as soon as the language supports referencing statics in const.

Kevin: A reason to keep the function is if we want to have a `static NOOP: Waker` later. But the normal use case wants a reference.

Kevin: So, I don't think there's a reason to keep the function.

Amanieu: My objection is that this constant is different than most of our other constants.

Kevin: As the author of the PR, I'm inclined to close this in favour of doing nothing.

Kevin: matching on it in a pattern/match is not useful

David: matching on this won't work, it doesn't derive partialeq

Kevin: aestetically, it might be nice if it is NOOP rather than noop() to make it clear it doesn't "do" anything, but that might be a weak argument

Kevin to write conclusion notes on the PR.

David: Should we stabilize noop()?

Mara: Stabilize it as `const fn` and add the 'stable address' guarantee later? Or stabilie it as non-const `fn` with stable address guarantee, and add `const` later?

David: So with the current implementation, you can't compare the vtable?

Kevin: There's no guarantee, but it's likely to be the same.

Mara: Not sure if that's likely.

(Discussion about whether the `noop()` method should be `const`.)

TC: For many use cases I'm aware of, `noop` needs to be const to make a const `Context`, similar to the code above.

Amanieu: not convinced how useful a stable address guarantee would be. seems fine to not support that optimization.

Kevin: we could have an API to check if a waker is noop, without specifying how it works.

Amanieu: happy to stabilize noop() as it is today

David: So that will rule out a meaningfully noop comparison unless the language feature happens.

Kevin to close this PR

Mara: Would be nice to see the tradeoff between 'const' and 'stable address' documented somewhere before stabilizing noop().

### (nominated) rust.tf/123203 *Add `Context::ext`*

Amanieu: This allows attaching any data to Context.

Mara: *one* data only ;)

Mara: I can see why this is useful but i hate everything about it ^^'

Josh: Same

Amanieu: Who is going to access this extension data? The runtime?

Eric Holk: A way of threading data from the runtime to the futures provided by that runtime.

Kevin: Two parties involved: Task executor (creates the context), and leaf future. The leaf future wants to cooroporate with the runtime. This is a way to do it other than with a thread local.

Kevin: The other thing is how to alloc collaboration between different runtimes.

Josh: Appreciation for Eric's and Kevin's detailed explanation of why this is needed. Feeling hesitant to add it on that basis. Concretely: there are multiple different approaches to interoperability, depending on how much we care about different runtimes

Eric: Some interop things can be solved with e.g. io traits. interop can mean different things. i like this approach because it needs fewer language features.

TC: +1.

Josh: There was a different proposal for a runtime to provide all its types File etc. through a trait, but that got shut down. Sometimes the answer is simply 'that's not the approach we want to go with'.

Mara: It seems like a no-brainer to add this on nightly. It'll be nice to try this out and use the experience to find a better API. But will tokio etc. use this as an unstable feature?

Eric: That's a good idea, to use this to discover the API that we want. I think it will be used on nightly.

TC: +1.

Amanieu: happy to try it out on unstable

Josh: That's fine, but i'll object to stabilizing this API, so that should be known to those who experiment with it.

TC: Is there anything that might happen during experimentation that could change your opinion?

Josh: That might happen, but &dyn Any seems pretty bad and it'd have to be very convincing.

Mara: Let's accept this as unstable, make it clear it's just for experimenting.

Amanieu to accept.

### (nominated) rust.tf/122935 *rename ptr::from\_exposed\_addr \-\> ptr::with\_exposed\_provenance*

Mara: Makes sense to me, ship it.

Amanieu: seems fine.

Josh: Not objecting to this, but i think it should be symmetrical with expose/expose_addr/expose_provenance.

### (nominated) rust.tf/122964 *Rename \`expose\_addr\` to \`expose\`*

Mara: +1

Amanieu: some people prefer expose_provenance, which matches from_exposed_provenance.

Josh: Consistency with the previous item seems useful.

Mara: having `provenance` in the ptr creation methods is good and useful, and i think having a short version for both .addr() and .expose() is good.

Josh: Don't care strongly to bikeshed the specific names of this, but very much in favor of picking names that match and obviously pair.

Mara: It doesn't have to be symmetrical. you can call expose() first and then later pass addr() to with_exposed_provenance(). Also memory mapped peripherals are considered exposed.

Amanieu: prefer expose_provenance

TC: Perhaps the reason it seems odd to us is that we're returning both the address and provenance, so this path almost seems to lead to `expose_address_and_provenance`.

Amanieu: The provenance is exposed and the address is returned.

Eric: Was in favor of `.expose_provenance` at first, symmetry argument is compelling, also this is an advanced operation so a longer name makes sense. Discussion has shifted me towards preferring `.expose`. The ideal name isn't clear (e.g. `.expose_address_with_provenance`), so `.expose` let's use sidestep all this. We also have `.addr`, so having a shorter `.expose` makes sense since we probably want people to use `.expose` instead of `.addr` in many cases.

Mara: I guess i'm fine with either. But I'd prefer leaving the choice to the folks who use it.

Josh: Fine with pretty much all options that make the two APIs symmetrical.

Mara: Sounds like the only option that works for all is: `with_exposed_provenance` and `expose_provenance`.

Amanieu: C.f.:

https://doc.rust-lang.org/nightly/std/ptr/fn.without_provenance.html

Amanieu to reply.

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

Skipping because we've painted too many bikesheds today.

### (nominated) rust.tf/123168 *Add \`size\_of\` and \`size\_of\_val\` to the prelude*

Josh: There was a lint change that made imports of things we subsequently add to the prelude generate a warning lint. Does that affect how we handle adding functions to the prelude?

Amanieu: Would also like to add other operations from `std::mem` to the prelude. Want to do that as a separate PR though.

Mara: I think it's valuable if we only use editions in prelude for traits and not for other items.

Mara: That lint should probably be fixed regardless.

Amanieu: also align_of for consistency?

Mara: +1

Josh: I'd like that.

Mara: FCP can start.

Mara: For the lint, I think the discussion on the lint should be resolved separately. Depending on the outcome, we can add it to all editions or 2024 edition.

Josh to update title and start FCP.

### (nominated) rust.tf/123197 *Tracking Issue for fn const BuildHasherDefault::new()*

Mara: This is just a new unstable method? Just r+?

Amanieu: Previously you needed Default::default(), but this adds a ::new() method that is a const fn.

Amanieu: I'll just r+

### (waiting on team) rust.tf/108684 *Clarify drop\_in\_place safety*

Mara: Seems reasonable to promise, but the exact proposed docs don't seem great. "As far as the compiler is concerned" etc. is not clear.

Mara: Looks like they are already working on finding better wording. See review comments.

Amanieu: waiting on opsem?

Amanieu to remove libs-api label.

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

TC: This is waiting on WG-async, not on T-libs-api.

(Various discussion around how much the async-fn-in-trait-based solution is blocked on, and whether we want to block on that.)

(Some discussion about having a list of lang features needed and what they're blocking.)

### (waiting on team) rust.tf/122291 *Stabilize \`const\_caller\_location\` and \`const\_location\_fields\`*

Finished FCP, now waiting on author.

### (new change proposal) rust.tf/libs359 *Explicit signedness casts for integers*

Josh: yes please

Mara: Prefer cast_* over other options.

Amanieu: to_* implies value preservation.

Accepted.

### (new change proposal) rust.tf/libs360 *make FromResidual #\[fundamental\]*

Skipped. Inadequately justified.

### (new change proposal) rust.tf/libs361 *Add \`try\_all\`, \`try\_any\`, \`try\_position\` and \`try\_rposition\` methods to \`Iterator\` trait*

Accepted. (Please use `try_fold` instead of `for` for the implementation.)

### (new change proposal) rust.tf/libs362 *Make \`ptr::from\_raw\_parts\` more general*

### (new change proposal) rust.tf/libs363 *Un\-specialize impl ToString*

### (stalled change proposal) rust.tf/libs255 *Adding \`set\_route\` to \`sys::unix::net\`*

### (stalled change proposal) rust.tf/libs184 *Add \`setsid\` method to \`CommandExt\` trait*

### (stalled change proposal) rust.tf/libs194 *Fix:Introduce an interface to expose the current \`Command\` captured env var logic*

### (stalled change proposal) rust.tf/libs210 *Add associated consts to f32, f64 for mathematical constants*

### (stalled change proposal) rust.tf/libs181 *\`Cow::map\_borrowed\`, \`Cow::map\_owned\`, and \`Cow::map\`*

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