---
title: Libs-API Meeting 2025-07-01
tags: ["T-libs-api", "Libs Meetings", "triage-meeting", "minutes"]
date: 2025-07-01
discussion: https://rust-lang.zulipchat.com/#narrow/channel/259402-t-libs.2Fmeetings/topic/Meeting.202025-07-01/
url: https://hackmd.io/q2mnfrvFThSbRLzXcY84Yw
---

# Libs-API Meeting 2025-07-01

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, Mara, Josh, David, Chris Denton, The 8472, Martin, Tomas, TC

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

13 rust-lang/rust T-libs-api FCPs

- merge rust.tf/141555 *Tracking Issue for \`#!\[feature(const\_float\_round\_methods)\]\`* - (3 checkboxes left)
- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* - (5 checkboxes left)
- merge rust.tf/129333 *Tracking Issue for \`lazy\_get\`* - (3 checkboxes left)
- merge rust.tf/141840 *If \`HOME\` is empty, use the fallback instead* - (3 checkboxes left)
- merge rust.tf/127213 *Tracking Issue for AVX512\_FP16 intrinsics* - (3 checkboxes left)
- merge rust.tf/136306 *Tracking Issue for NEON fp16 intrinsics* - (3 checkboxes left)
- merge rust.tf/141520 *Tracking Issue for const {OsString, PathBuf}::new* - (3 checkboxes left)
- merge rust.tf/70530 *Tracking Issue for {BTreeMap,BTreeSet}::extract\_if* - (3 checkboxes left)
- merge rust.tf/141994 *add Iterator::contains* - (4 checkboxes left)
- merge rust.tf/141744 *Stabilize \`ip\_from\`* - (3 checkboxes left)
- merge rust.tf/140956 *\`impl PartialEq\<{str,String}\> for {Path,PathBuf}\`* - (3 checkboxes left)

[nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [joshtriplett (11)](https://rfcbot.rs/fcp/joshtriplett), [m-ou-se (11)](https://rfcbot.rs/fcp/m-ou-se), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [Amanieu (2)](https://rfcbot.rs/fcp/Amanieu), [BurntSushi (10)](https://rfcbot.rs/fcp/BurntSushi), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay)

### (nominated) rust.tf/76354 *Does \`\[T\]::array\_chunks\` really need to be an iterator?*

Amanieu: We stabilised `as_chunks` but not the `array_chunks` iterator.

David: The signature this is asking for is what we stabilized. Should we just close the issue? Now that we have stabilized `as_chunks` should we keep `array_chunks` or just rip it out?

Amanieu: I'd say rip it out.

Josh: `as_chunks` gives you a full reference of the slices of all the chunks at once wheres `array_chunks` iterates over them. Is there any issue having a huge array that you translate it into a massive slice -- e.g. 1M array of 2-byte chunks.

The 8472: You already have a reference.

Amanieu: This is on slices, you already have a slice, you're just chunking it differently.

Amanieu: FCP close?

Josh: Closing array_chunks on slices specifically makes sense.

The 8472: We also have `array_chunks()` and `next_chunk()` on iterators.

Amanieu: And this is all on a separate tracking issue so we're fine.

Amanieu: Decision: close this FCP. We're chosing the option 2.

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

Amanieu: I don't think there's been any updates on this. I haven't made any progress summarizing notes from the last meeting.

Josh: I'd be happy to pair on that or similar. We could set up a time later this week?

Amanieu: Sure.

### (nominated) rust.tf/138217 *Turn \`Cow::is\_borrowed,is\_owned\` into associated functions.*

Josh: I nominated this one based on the discussion that happened on this issue. Because `Cow` implements `Deref`, these shouldn't be methods but associated functions. `Cow` does have methods such as `into_owned` and `to_mut`.

The 8472: Does the featuree that suppresses the nightly methods suppresses `deref`?

Josh: I believe there's a warning telling you that if these get stabilized, you may have issues.

The 8472: Can we check with crater?

Josh: The most straightforward way would be a PR that stabilizes these and put that PR through crater. See if it causes any breakage.

Josh: Either way this is not the correct approach.

David: Why not have them as associated functions?

Josh: You could just as easily write a `match` expression or a `matches!` macro.

The 8472: `Cow` is not fundamental, so this is allowed breakage.

Josh: But if crater shows that they'd break a lot of code then we should just drop these.

David: I find myself not using the `matches!` macro, usually my code is more explicit. I'd expect some pushback on just deleting these.

Mara: I'd just merge this PR (https://github.com/rust-lang/rust/pull/138217).

David: That's ultimately my preference too.

The 8472: If there's no breakage we can keep them as is.

Amanieu: Should we consider changing `into_owned` and ?? to be an associated method over the edition?

The 8472: You can always call `deref` if there's ambiguity. Name conflicts will be very obvious.

Mara: This is about unstable methods.

The 8472: That's why I think we should check for breakage. Why we'd do this?

Mara: Because we shouldn't add more methods on deref.

Josh: We should be aware of methods that could add breakage. But I'd consider it an anti-pattern to call `Arc::clone()` rather than `arc.clone()`

The 8472: For example `Vec` is `Deref` but we won't remove its methods

Mara: Not on arbitrary types

Josh: For `Cow` it can be used on arbitrary types. It would be convenient to add `into_owned` and `to_mut`. Describing them as anti-pattern is not a mistake to use.

Mara: I think we shouldn't have them but it's too late.

Amanieu: We should either decide it's okay to have methods taking `self` on `Cow` (and close this PR). Or decide we should only have associated methods that don't take `self` in which case we should merge the PR and over edition fix `into_owned` and `to_mut`.

Mara: Neither of these have consensus on this team.

Josh: I agree in principle Amanieu, but in practice half people will disagree with either option.

Amanieu: Doing nothing means these will remain unstable.

Josh: That's why I think we should make a decision on these methods. If we don't have a consensus on keeping them as methods, then we can debate having them as associated functions. But do we have a consensus on keeping them as associated funcitons?

Mara: Yes. I'd rather write `Cow::is_borrowed` instead of a `matches!` macro

The 8472: even if the `is` syntax happens?

Mara: Will that happen? If that happens, that seems enough.

Josh: Given there are blocking objections to keeping these methods as methods, what's in nightly won't ever be stabilized because there are blocking objections. So closing this and opening another tracking issue for `is` syntax etc.?

Mara: Sounds good.

Amanieu: Sounds good.

Josh: I can summarize that in the issue.

### (nominated) rust.tf/140153 *Implement \`Debug\` for \`EncodeWide\`*

Amanieu: EncodeWide takes in OsStr and produces `Vec<u16>`. What should the debug output be?

Mara: Print out the remaining OsStr?

Amanieu: Yeah we could do that.

Mara: The debug could miss infromation if we write out the OsStr, but that seems fine.

The 8472: We have other Debugs that print out mostly UTF-8 and print escaped charcters

Chris Denton: That output would produce illegal Rust.

The 8472: Is there any way we could turn this back into legal Rust? We don't have any UTF-16 String constructors.

Mara: We can address this. The exact Debug output is not a stable guarantee.

Josh: Agreed.

Amanieu: What's the justification for the padding?

Chris: That's just to make it clear when you're using u+XXXX unicode syntax

### (nominated) rust.tf/140808 *Implement Default for &Option*

Amanieu: That's particularly cursed but works.

Josh: Given that it works, it makes sense given there's an obvious default for this.

Mara: Is there any other reference where this works?

David: We have this for all the string types (&mut str, cstr etc.)

Josh: Should we start an FCP?

Amaniou: This shouldn't block the future implementation of const impl traits.

Josh: There are reasons this could cause breakage unless we drop this immediately after it's stabilized. But otherwise, no.

Josh: I'll start the FCP.

David: Would we know the rough signature of the const impl? `impl<T> Default for &T where T: const Default + Sync + Copy` If you call the Default impl from two separate threads, you could get the reference to the same static.

Amanieu: !Drop is not a problem because ??

Josh: Considering all of the additional bounds, I think people should just implement this for the reference types they actually want rather than a blanket impl.

Amanieu: Can they?

Josh: You can implement a trait for your type if you define your type.

Mara: People can already implement traits for the types now.

Josh: They can't have `const Default` in stable Rust. But regardless, I think there are several reasons not to have the blanket impl.

TC: Maybe write that down on the issue?

Amanieu: Are we changing our mind?

Mara: We're just discussing future possibilities.

David: I still support this.

Amanieu: How does work with an `Option` that has a `Cell` in it? The underlying memory is mutable.

The 8472: But then it's not `Sync` right?

Amanieu: It's not `Sync` but the `default` method will always retur the same pointer. So all the threads will get the same underlying address.

The 8472: If it's not `Sync` then `&` is not Send and it's not allowed in a static.

Amanieu: It seems sound, I'm just surprised it even works.

Amanieu: We should add it because if we don't add a `Freeze` here that should ?? once we have `const Default`

Josh: I want to say we don't want the general implementation given all the caveats.

Mara: People can write their own Option type and implement `Default` for it.

Amanieu: Yes.

Amanieu: Would we hypothetically want Default for `&u32`?

Josh: Yes, there's an argument for what that should be.

Amanieu: That's the argument for implementing this for every type that implements `Default`.

TC: Seems so, but I'd love to see the analysis written down for this.

Amanieu: I'll add a concern for the more general `Default` implementation.

### (nominated) rust.tf/141219 *Change \`{Box,Arc,Rc,Weak}::into\_raw\` to only work with \`A = Global\`*

Amanieu: `into_raw` currently leaks the allocator. Which means you can't roundtrip these with `from_raw`.

Josh: Wolud it be possible to make this work with any allocator that's `static`? Rather than just the global allocator?

Amanieu: No because an owned allocator is `static`. You can't use it with `from_raw` because `from_raw` gives you a bog with the global allocator.

The 8472: You could do it for allocators that are `Copy` or `Clone` because you could get a copy out before you do it.

Amanieu: I'd prefer people were just forced to use the allocator directly.

Josh: There's no way for us to say "must be a zero-sized type" either

Amanieu: Being a zero-sized type isn't enough -- it could be a singleton.

David: I support the PR.

David to reply.

### (nominated) rust.tf/142849 *Add \`Write\` implementation for \`\[MaybeUninit\<u8\>\]\`*

Amanieu: I think we already have a `write` method for `[MaybeUninit]`.

Josh: Somebody observed that it is a bit questionable to rely on the `SafeWrite` trait to have written the amount it said it had written.

The 8472: Since we own the trait, we can promise this particular implementation is safe for `unsafe` code.

Amanieu: We have a method on `[MaybeUninit]` called `write_copy_of_slice`.

The 8472: Is the motivation here mentioned?

Josh: I'd assume the rationale is being able to write incrementally.

The 8472: As an inner implementation of outer write which also deals with bytes.

Josh: I'd argue that any user of this probably wants borrowed buf ??

The 8472: This one would be insta-stable.

Josh: Do we have the current status on what the blockers are for stabilizing borrowed buf?

The 8472: I think people are still discussing what the correct trait is?

Josh: Are there alternatives to the current proposal?

The 8472: I havent't paid much attention to the discussion, just saw that some happened.

TC: Is there any reason not to do this? On the first pass this seems reasonable to me.

Josh: It does seem fine.

Amanieu: I suppose. It's technically safe and sound. You need unsafe code to get the initialized slice back out, but that's your own fault.

Josh: I'd argue it'd also be worth having an owned implementation of `Cursor` on `[MaybeUninit]`. The same way we have an implementation of `Cursor<u8>`.

Mara: Same problem, you don't get an initialized init after that.

Amanieu: https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.write_copy_of_slice

Amanieu: I feel like this is the wrong API.

Mara: We need a more complete example for motivation / use case.

The 8472: This is the `Writer` side, not the `Reader` side. The `Writer` side is easier: we only need to initialize the bytes that are actually written so it seems much safer.

Mara:

The 8472: You can trust the `Write` implementation in std

Amanieu: But e.g. serde_json will write something and you don't know how many bytes it's written.

Mara: It'll truncate the slice.

TC: It seems clear how you'd use this in a non-generic context and how that'd be safe and useful.

The 8472: We should at least note the caveat about passing it to 3rd party code because you can't be sure how much has been initialized.

TC: Unsafety contracts often rely on the correctness of safe code.

The 8472: But you can't necessarily trust that some 3rd party crate will always do the right thing unless you inspect the source code. And then you need to inspect it for every version and that's brittle.

TC: Is the concern that it would return a different value than the correct amount of bytes written?

The 8472: In the generic T: Write case yes. In a concrete case of taking a &mut Maybeuninit it could mutate the slice length. Possible source of confusion.

Amanieu: I think we need to see a clear example.

TC: The example The 8472 gave here should also be written to the issue so the safety concerns can be analyzed.

Amanieu: I'll ask for the motivating example here.

### (nominated) rust.tf/143191 *Stabilize \`rwlock\_downgrade\` library feature*

Amanieu: Any objections? Should I just start the FCP?

Amanieu: The only downside is that is we can't go back to pthread

Josh: At this point we're entirely too much cooler than pthread and I don't see us going back to that -- not after Mara's work.

### (waiting on team) rust.tf/65816 *Tracking issue for \`vec\_into\_raw\_parts\`*

Stabilization report: https://github.com/rust-lang/rust/issues/65816#issuecomment-2906929239

Associated method? https://github.com/rust-lang/rust/pull/141509

Josh: Is there some rationale given for why we'd want these to be associated methods?

Amanieu: ...

Josh: As far as I can tell, we don't have that as a method.

Amanieu: `to_raw_parts`. It's on raw pointers.

Josh: I'm not seeing anything this would conflict with.

Amanieu: So this is fine.

Josh: I'd expect to just call this as a method.

Amanieu: I'm happy to stabilize as is.

TC: Changing it to a method?

Josh: It's already a method. There's a PR proposing we not make it a method -- we should close that.

The 8472: Do we need a separate .. We could also change this one -- it's just a simple method call to change it into a pointer. Is there a benefit to having both?

Amanieu: Consistency. We should have at least one of them.

Josh: We should have a method that returns `NonNull` but given we have a stable `from_raw_parts` I'd argue that `into_raw_parts` should return the same type.

The 8472: You can't -- it dosen't take a tuple.

Josh: I'm talking the same there parameters in the same order. That's the normal convention for multiple returns. That's different from `into_raw` parts returning a completely separate type.

The 8472: But you can't pass the output directly. You have to pack/unpack it.

Josh: There is a separate method that returns `NonNull`.

TC: The usecase here is you call `into_raw_parts`, you get a `NonNull` and you want to pass it to `from_raw_parts` -- what do we do here. It seems obvious from a language level that `NonNull` could coerce to `*mut`, i.e., we could do language work to make this round-trip more syntactically natural.

Josh: It's not obvious to everyone here.

The 8472: If you're already processing the output already, why do they have to match?

Josh: Why do they have to not?

The 8472: The old one is already stable. If you're processing, you might as well do the conversion.

Josh: I want to question the "might as well".

The 8472: This isn't something written frequently, not something it needs to be super concise.

Josh: The last dozen arguments we had about stabilization is "it isn't used very often". I want to reject that argument.

The 8482: `from_raw_parts` is an older thing where we didn't have `NonNull`.

Amanieu: Are you saying to deprecate `from_raw_parts` in favor of `from_parts`?

The 8472: Essentially.

Amanieu: I'm in favour of stopping using raw pointers in place of `NonNull` entirely.

The 8472: Variance could be a problem?

Chris: You can make a helper type to go around that problem.

Josh: There's also `Unique` which IIRC was created specifically to be that wrapper.

Amanieu: `Unique` has no-alias guarantee.

TC: I'm pretty sympathetic to the consistency argument. But there's a difference between returning and accepting. There are cases when you return -- you can return something with a stronger guarantee than what you can accept back. Here it's known to be non-null, so it's strange to not represent that in what is returned.

Amanieu: Every single method called `into_raw` currently returns the raw pointer, not `NonNull`. I wonder if this is something we can do over edition. To return `NonNull` instead.

Josh: I'm all in favor in the idea of deprecating `into_raw_parts` or replacing them with `NonNull`. But I'm not in favour doing it here on a one-off basis.

TC: I'm sympathetic to that.

Amanieu: With that in mind, we should be happy to stabilize this with a raw pointer here. And if we make the change later it'll be a coordinated effort is fixing it here too.

Chris: Can we change a function signature over an edition?

TC: No, but we can e.g. change the resolution over an edition.

The 8472: Should this be a struct with named fields rather than a tuple to avoid confusion with length and capacity.

Amanieu: I think it's pretty obvious this matches the `from_raw_parts`.

Josh: If we're talking about changes in plans in the future, would it make sense for `into_parts` to return some kind of tuple struct?

TC: In my ideal world we would have some type of three-tuple struct. And we'd have a trait that has has this method and then we'd implement the trait.

The 8472: Tuple structs also don't have named fields.

Josh: We could have a named tuple type that has the usual numbered fields of a tuple but also has explicit methods that return the values. The annoyance of that would be having to write that in the return value when pattern matching it.

The 8472: Like we said earlier, you don't immediately feed it back, you do somethnig with it.

Josh: My impression is most people would immediately destructuring it into three named fields.

TC: We have that lang RFC for struct inference (`_{`) that might help here.

Josh: I'm all for doing that, I'd love to see the RFC ship. But in the absence of that, I'd do the three-tuple and later on a migration.

TC: I think we've answered all three open questions.

Amanieu: I'll do an FCP close on the PR and FCP merge on the tracking issue.

TC: Make sure you note the change about the associated method rather than function as that's different from the stabilization report.

Amanieu: Do we have any thought about `into_parts` and `from_parts`.

Josh + TC: Ship it!

The 8472: Do we have to address the variance?

Amanieu: `NonNull` is covariant which doesn't matter because this is an owned pointer and I think it's fine for owned poiters to be covariant.

TC: The methods are `from_parts` and `into_parts` and some are `into_non_null`...

Amanieu: Those are on `Box`.

TC: Right. Really want `into_ptr` here.

Amanieu: We have `as_ptr` which returns pointer types.

TC: The main drawback here is the unfortunate `_non_null` names we're pushed into.

Amanieu: Yes, indeedd. We could wait for the edition mechanism and fix this generally.

Amanieu: Let's just defer that one for now, then.

### (waiting on team) rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`*

Not waiting on us.

### (new change proposal) rust.tf/libs611 *OsStr::starts\_with*

Amanieu: I thougt we had a more complete version of this proposed. 311 Pattern methods for `OsStr`: https://github.com/rust-lang/libs-team/issues/311. That was accepted, just not implemented.

Amanieu: We can close this and point to 311.

The 8472: This needs a tracking issue.

Chris: Maybe suggest that they start implementing it?

### (new change proposal) rust.tf/libs610 *ACP: Add a \`oneshot\` channel*

Josh: Given precedent in the ecosystem this seems like a reasonable proposal. But let's not write our own bespoke implementation.

The 8472: Doesn't the crossbeam one have a special case? We could probably expose that somehow?

Josh: Yeah.

The 8472: It taske `self` so it consumes the sender and receiver side.

Josh: So on the type level it enforces that you can only send it once and receive once.

The 8472: A common usecase is to have a channel and then send the oneshot channel.

Josh: I'm assuming both `Sender` and `Receiver` would not be `Clone`?

Amanieu: Yes.

The 8472: It doesn't interact with async.

Amanieu: Tokio will still have their own copy of it.

The 8472: Generally when bridging sync and async it's good to have a channel that supports both. E.g. connecting an async `Sender` and sync `Receiver` and vice versa.

Amanieu: If you're taking `self` you have to receive or if you fail to receive you can't try again.

Josh: I'd expect the obvious solution would be to transfer the ownership to the `Error` type and then be able to get it trivially back after the error.

Amanieu: The `oneshot` crate has `TryReceive` which doesn't consume self and `Receive` to use self.

Amanieu: Counterpoint: why can't people just use the `oneshot` crate?

TC: We have channels in the standard library; it'd be weird to not have this and complete the natural set.

The 8472: We are adding mpmc so it's completing the full set. Maybe we can look at the bigger picture when we're trying to stabilize both.

Amanieu: This ACP only proposes `send` and `receive` methods. The `oneshot` crate supports a lot more. Do we want to add them? Our channels have a different `Sender`/`Receiver`.

The 8472: It's common in the ecosystem to have different sender/receiver types. And we have different sender types already.

Amanieu: I'm personally unconvinced but I won't block it.

Josh: I think it'd be valuable to have in the standard library and we've demonstrated proof this is something people find useful.

The 8472: Channels don't need runtime so we could suport async polling with these? That would be the first time we implement support in the standard library.

Amanieu: I think we'd need a runtime.

The 8472: Channels are runtime-independent.

Amanieu: Channels would need to block and you'd need a runtime to be able to do that.

Josh: It's useful to for channels to be able to communicate between sync and async code. Have one end in a thread and another in a task.

The 8472: In my experience this provide a lot of value connecting them.

Amanieu: That seems like a large complexity.

Josh: I know that [flume](https://crates.io/crates/flume) does this and it's also faster. So it makes sense at one point to add that.

The 8472: There's a lot of value in being able to bridge different runtimes, bridge sync and async.

Josh: I'm using it mainly as a proof that it's possible to have sync and async on the same type.

The 8472: Agreed.

The 8472: I've checked the crossbeam issue tracker and the maintainer is not interested in adding async compatibility.

Amanieu: I believe the algorithm is incompatible.

The 8472: I think having a oneshot channel is useful. But having a difficult path supporting async is limiting its future use.

TC: That's true for all channels we have. We can accept that all our channels are synchronous, we'll fill the gaps and we can talk about adding async channels later on.

Josh: Agreed.

TC: OK. ACP accepted?

The 8472: We're also not objecting to additional API surface like try_receive, right?

Josh: Adding `recv_timeout` or `recv_deadline` seems fine. What would `try_receive` do?

The 8472: It takes `self` and if nothing is available, it returns `self` so you can try again.

### (new change proposal) rust.tf/libs609 *ACP: Add Option::reduce*

Amanieu: I could have sworn we've rejected this already. Found it: ACP 328: https://github.com/rust-lang/libs-team/issues/328

Amanieu: This is exactly the same as 328.

Amanieu: It does seem like a common pattern.

TC: He makes a case that it could be done with an iterator but then it must be `FnMut` rather than `FnOnce`

Josh: The github code search they linked to is not actually reliably identifying cases for what they want. A lot of them are more for `zip` or `zip_with`. Some of them would warrant `Option::merge` but not all.

Josh: So do we thing this is a sufficient case for adding `merge`?

Josh: `zip` is the same signature but it only gives you the result if both of them are `Some`.

TC: I think the presence of `zip` is a strong argument in favor of having this. If `zip` is present, you also want to have this.

Amanieu: It seems `zip` is like an `and`? I'm inclined to accept this.

TC: The author highlighted that issue in the search but mentioned that many of those are highlighting `merge`.

Amanieu: Ship it!

Amanieu: Naming? `reduce` or `merge`?

Josh: I'm in favor of `merge`.

The 8472: We have `reduce` on `Iterator`.

TC: And we have a `zip` on `Iterator` too.

The 8472: I think `reduce` is fine.

Josh: Sounds like `reduce` probably is the correct answer, then.

The 8472: Do we want to take the same types? Different ones?

Amanieu: `zip` takes two different types. `Iterator::reduce` doesn't imply `Into`. `zip` doesn't use the `Into` either.

The 8472: I was thinking `fold`. Would there be issues with type inferrence?

Amanieu: Probably.

The 8472: The closure sholud provide the necessary constraints.

The 8472: I think it's strictly more general and doesn't have an inferrence downside.

TC: It should. But if it doesn't we'd find out in nightly by doing the more generic one in nightly and seeing.

Amanieu: That makes sense. Let's do that then.

impl<T> Option<T> {
    fn reduce<U, R, F>(self, other: Option<U>, f: F) -> Option<R>
    where
        T: Into<R>,
        U: Into<R>,
        F: FnOnce(T, U) -> R,
    {
        match (self, other) {
            (Some(a), Some(b)) => Some(f(a, b)),
            (Some(a), _) => Some(a.into()),
            (_, Some(b)) => Some(b.into()),
            _ => None,
        }
    }
}

TC: I'll write it up.

### (new change proposal) rust.tf/libs607 *ACP : Enshrine the fact that slices are structurally pinning through safe accessors*

Amanieu: We talked about this last week about duplicating the whole slice API with Pin slices.

TC: We accepted this one.

We were just missing the acp-accepted label.

TC: Someone pointed out that we did something different on `Option`: https://github.com/rust-lang/libs-team/issues/607#issuecomment-3002311968

TC: The way I sketched it out is that it abstracts over pinning and over mutability. We get to use the same name both for pinning and mutability.

Josh: Do we want to do the same thing for `Option`?

TC: By basically doing the same method for `Option`? That would probably be inherent in this idea.

TC: Does that cause us any inference problems? They'd be the same methods so it'd be OK in any case.

TC: I'll add a note that we've discussed that we're accepting as part of this ACP replacements, using this approach, for any existing projections, such as the one on `Option`.

### (new change proposal) rust.tf/libs603 *A \`Static\` receiver type for dyn\-trait methods that do not take values*

The 8472: I think that's about invoking a dyn method on

Amanieu: Looks like having a raw vtable pointer?

Amanieu: This might touch lang as well.

Josh: There's a different proposal in flight right now trying to make it so that arbitrary trait methods can be dyn compatibla. This is based on the init trait.

TC: And Taylor has a different proposal.

TC: dyn* has been removed.

Josh: It sounds like they're trying to argue that even if a given type won't be available via dyn trait, a static of that would be. And then it's effectively a smart pointer to no data. That could be usable as a smart pointer dispatcher you could call methods on but it doesn't have a type.

Josh: As far as I can tell, this wrapper type makes it possible to implement some traits on a given dyn trait without that trait being dyn.

TC: I'd need more time to look at this. I think this needs something more like an RFC.

Josh: I think they should be coordinating with the folks making proposals for universal dyn-compatibilty (either Taylor or Alice & co.).

TC: That's what I mean -- whether that's an RFC, pre-RFC or a design doc they need to write it up in a broader context and then submit it for broader consideration.

Josh: If you want them to write-up more than they have, you should tell them what you'd like to see rather than referencing an RFC or pre-RFC.

TC: A lot of the stuff is not available yet.

Josh: We can point them at the zulip thread. I just don't want them to write up a RFC without being aware of the competitors.

Amanieu: if you look at the `EthernetPayload` example: it has a fake self type, but that self type doesn't point to any data.

The 8472: Which problem are they trying to solve? That they have a value but can't call a receiverless method on it or that they don't have a value?

Amanieu: The caller knows the type. But they don't necessarily have a value.

The 8472: This would be sort of a runtime type descriptor?

Amanieu: Yeah.

Amanieu: This needs to be sent to people doing other similar stuff.

Tomas: Would it make sense for Alice and Taylor to be told about this thread and have them reach out? Given their stuff isn't fully written down.

TC: The right thing would be to CC Alice, Taylor and Benu, replying this is broader and that this nedes to be considered as part of the set of all the solutions.

TC: To me it's not written in the way that's laying out the full problem and laying it out in the broader context, and that's what I think this is going to need.

Josh: I'm not arguing against the idea asking for more information. Just against asking them to make this an RFC.

Josh: We should point them to a couple of zulip threads, ask them to contrast those proposals with yours. Does this still make sense given one of these? What are the pros and cons?

TC: That makes sense. When I said something like an RFC, I meant exactly this -- putting it in a broader context, considering the alternatives. That analysis is missing here. Tomas, let's leave this to you.

*Tomas will reply.*

### (new change proposal) rust.tf/libs602 *ACP: add \`array::from\_raw\_parts()\`*

Amanieu: Two weeks ago wi asked for clarification for the intent. I'm still not quite satisfied.

Amanieu: Seems to be a method that takes a raw pointer to T and reads ?? out of it

Amanieu: That's literally `.cast().read()`

The 8472: This is a more constrained cast method basically.

Amanieu: The method they want is `cast_raw().read()`. This has nothing to do with `from_raw_parts`.

Josh: Agreed, this shouldn't be`from_raw_parts`. But having a cast array method sounds great.

Josh: Having a function that takes a pointer and an `N` and creating an array seems like a good function.

Amanieu: is cast array worth it when we already have cast?

Josh: Generally anything that is more constrained sounds like a good feature. `cast` can do anything.

The 8472: We have a bunch of other more specific casts. e.g. going from `T` to `[T]`.

Amanieu: I'll write a response asking if `cast_array` is what they're looking for. Because once you've done that you can do `.as_ref` / `as_mut` etc.

### (new change proposal) rust.tf/libs589 *\`ptr::fn\_code\_ptr\` for explicitly getting an opaque pointer of a function*

Amanieu: I have a new proposal here: https://github.com/rust-lang/libs-team/issues/589#issuecomment-2981331798

Amanieu: `FnStatic` callable but doesn't take self as an argument and can be cast to a function pointer.

Amanieu: This would probably require an RFC. What is the next step here?

The 8472: Ask other teams if they have any concerns?

TC: What's the lang question?

Amanieu: `FnStatic` is an extension of the `Fn*` traits. We need to file support for `FnStatic`. It's a subclass of `Fn`. More specific tahn `Fn`.

Josh: This is a version of `Fn` where you're not taking a closure?

Amanieu: Yes, this doesnt' take self at all.

Josh: You'd expect anything implementing `FnStatic` to implement all the other things?

Josh: Why is it taht `addr` returns a `usize`. And `as_pointer` returns `NonNull`. Is there a reason `addr` doesn't return `NonZero<usize>`?

Amanieu: No, it could be `NonZero` is fine.

Josh: For new things, we should add the `NonZero`.

Josh: It is intended behaviour that when you have an entry point and an address of that yount, you'd be able to pass that to `from_ptr`, get a static of that and then call it.

The 8472: The compiler would need to instantiate a unique type for each JITed function

Josh: So it seems like it'd be useful to be able to do that in the future but it doesn't need to be possible on the day one.

The 8472: You'd need a type constructor.

TC: My procedural suggestion. This is a fine Libs-API ACP to accepte. And when we create a tracking issue we tag lang and set up a lang experiment which Josh and I can champion.

Josh: I have enough championing on my plate.

TC: Amanieu can champion this, he's a lang-advisor.

### (new change proposal) rust.tf/libs587 *ACP: \`try\_exact\_div\` method on \`NonZero\<{integer}\>\`*

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

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

### (stalled change proposal) rust.tf/libs347 *Context reactor hook*

### (stalled change proposal) rust.tf/libs304 *ACP: Avoid the common mistake of \`for x in 0u8..\`*

### (stalled change proposal) rust.tf/libs195 *OS\-level \`thread::Builder\` priority and affinity extensions*

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

### (stalled change proposal) rust.tf/libs462 *impl fmt::Write for BufWriter*

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

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

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

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

### (stalled change proposal) rust.tf/libs111 *Restructure ptr\_metadata to minimal support*

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