# Libs-API Meeting 2025-11-11

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

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

## Agenda

- Triage
- Anything else?

Urgau: ACP automation process: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/rustbot.20automation.20for.20ACP/with/554494199

Urgau: on Compiler we have automation of major changes. We automate it from start tofinish. When a proposal is open, we create a zulip thread, the whole discussion happens on zulip. When someone proposes merge and seconds it, this starts a 10 days comment period and peple can propose concerns. Adter the ten days, the major change is accepted and a tracking issue is automatically created.

Urgau: I think you do something similar. Would you be interested in having such an automation?

Josh: As long as the automation matches how we normally handle the process would be great. We've only been discussing ACPs in meetings. If we want to make it async, this would be great tooling to have.

David: My preference would be to make the ACP less of a process. So having someone saying "this makes sense to me" and start opening tracking issues. The automation should help us guide consensus within the team.

Josh: It makes sense to reduce the amount of process. ACP is a vibe check and general check for a new API. If we go that rout that we should have the process and automation, people will notice it. We could put things at the top of the agenda as things that got seconded, highlight and zulip. But we should have alighter-weight process.

David: The reoason for ACP when it was introduced was we were drowning in 100s of unstable library features. The tooling should help is with getting out of the queue from being unstable to stable.

Josh: I agree we should have tooling for that too but we'd have to build that. But here we can have tooling that the compiler team already has.

The 8472: Seconding would only cover a fraction of ACPs. It would only happen when they get attention and we have a huge backlog. It may be not as easy as just someone seconding it. We have a wide range of quality between ACPs

David: Do you think there's a difference between the quality of ACPs and MCPs?

The 8472: The MCPs come from compiler people who put a lot of care into them. ACPs are coming from random people who have suggestions.

David: I agree with that distinction. The other is: once the MCP is seconded, the work can move forward and everything that lasds is between the author and reviewer. The rest of the team is not involved. With ACPs theer's relatively small amount of work and the bulk of the work is a synchronous discussion during stabilization.

Josh: I can't think of an ACP that's accepted that doesn't require an FCP to ship it. ACPs aren't the only gate whereas MCPs definitely are.

Urgau: We require FCP for user-facing changes in the compiler too. MCP aren't enough.

Josh: You can change the compiler in ways that aren't that visible to the user.

The 8472: But in the library we also have implementation changes.

Josh: True but those typically don't have ACPs for them.

David: The main distinction is whether the preliminary process gates the bulk of the work or not.

Josh: Yes. The ACP once approved would let someone go ahead and do the implementation.

Amanieu: Is there anything we need right now? Even the automatic tracking issue creation is almost counter productive because in almost every ACP we require changes fromthe original proposal before we accept it.

The 8472: And it's good if the original author creates it because then we can edit it and update.

Amanieu: I like the idea of switching to the "second with no objections" model. But that can be discussed separately and I don't think there's need for automation.

The 8472: I think we tried that in the past and then switched to this process.

Amanieu: People in the team were'nt confident enough to second things without input from others.

Josh: In practice we weer finding a lot of them required some amount of design feedback that ended up needing a meeting anyway.

David: The blocker for getting ACPs through was not the comments and tags. The blocker was that no individual member asyncronously was confident to spear head. Tooling could help. Let's say the something watched thumbs up and after reaching a threshold and it would leave a comment proposing moving it forward. I think there would be value in pointing out 2/x

Amanieu: It's easy to check a box but to start the ACP/FCP itself needs more effort and confidence.

David: How about we use it for agenda. List items in the descending amount of thumbsup and fast track those during the meeting.

The 8472: We could also use the community thumbs up as a signal.

Amanieu: I'm not sure how consistent the signal is. I never use thumbsup unless it's part of a poll.

Amanieu: For now I think our current process is the best we have. What comes up a lot in our meetings is that everyone's ambivalent and not strongly in favour. If during our meeting one of us is strongly in favour of a proposal, we should seriously consider accepting it unless there are objections form anyone else. But I don't think we need automation.

David: I agree.

Josh: I think we should revisit our process at some point. But until then, I agree.

Amanieu: Urgau, thank you for bringing this to our attention.

## 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/146792 *Implement \`TryFrom\<char\>\` for \`usize\`.* - (3 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/146560 *Add the \`cpuid\` target feature* - (5 checkboxes left)
- merge rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16* - (1 checkboxes left)
- merge rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* - (4 checkboxes left)
- close rust.tf/136638 *warn on empty precision* - (3 checkboxes left)
- merge rust.tf/98407 *Tracking Issue for \`Exclusive\`* - (1 checkboxes left)
- merge rust.tf/145948 *Stabilize 29 RISC\-V target features (\`riscv\_ratified\_v2\`)* - (3 checkboxes left)
- merge rust.tf/146660 *Tracking issue for release notes of #146410: Iterator repeat: no infinite loop for \`last\` and \`count\`* - (0 checkboxes left)
- merge rust.tf/140808 *Implement Default for &Option* - (2 checkboxes left)
- merge rust.tf/141994 *add Iterator::contains* - (2 checkboxes left)
- merge rust.tf/135894 *Tracking Issue for \`atomic\_try\_update\`* - (3 checkboxes left)
- merge rust.tf/76314 *Tracking Issue for atomic\_from\_mut* - (2 checkboxes left)

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

- merge github.com/rust-lang/stdarch/issues/1935 *Make \`cpuid\` safe and update docs* - (3 checkboxes left)

[BurntSushi (9)](https://rfcbot.rs/fcp/BurntSushi), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [traviscross (1)](https://rfcbot.rs/fcp/traviscross), [Amanieu (4)](https://rfcbot.rs/fcp/Amanieu), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis), [scottmcm (3)](https://rfcbot.rs/fcp/scottmcm), [joshtriplett (3)](https://rfcbot.rs/fcp/joshtriplett), [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay), [the8472 (9)](https://rfcbot.rs/fcp/the8472)

### (nominated) rust.tf/libs688 *Initial state once cell value*

Amanieu: We responded to this last week. Theres' been some confusion here. StateCell must always have poison staet internally because it's a cell. It's only State that can decide externally whether to have poison or not. I'll reply to clarify the situation.

### (nominated) rust.tf/145457 *Experiment: Add \`where T: Default\` to \`Default for \[T; 0\]\` impl.*

Amanieu: Waffle asked our opinion on the documentation aspect. I don't believe it's a big deal.

Josh: I want to know how it would show up in rustdoc.

Amanieu: It will probably show as an implementationfor all N and a separate implementation for 0.

Josh: If that's how it apperas that's great.

The 8472: I think specialization already show up.

David: IF that's not how it shows up, we can make it show up. Rustdoc is very receptive to things like that.

Amanieu: The impls technically overlap but I don't think that it will be confusing.

The 8472: And you'll get the same behaviour anyway regardless whether it's zero-sized.

### (nominated) rust.tf/148589 *Rename \`DropGuard::into\_inner\` to \`DropGuard::dismiss\`*

Amanieu: Previously people suggested `DropGuard::disarm`. There were concerns it evokes images of violence and weaponry. One of the proposals wos dropbomb.

Amanieu: `dismiss` seems fine to me. That's wah'ts used in the Linux kernel.

Josh: `dismiss` seems clear to me, it's the most obvious from the ones proposed. Someone made an observation that it should be clear that the guard goes away but the thing inside does not and proposed different words. Someone proposed `reclaim`.

Josh: What if we call it `unguard`?

The 8472: What's the problem with `into_inner`?

Amanieu: It doesn't clearly indicate that you're suppressing the drop impl of the `DropGuard`

The 8472: It consumes the guard.

David: I like Josh's suggestion.

Amanieu: I like `dismiss`.

Josh: Dismiss is fine, I proposed something that doesn't require an English-language metafor and just state directly what it does.

Amanieu: One of the other reasons against into_inner is you'll be using this to dismiss the guard without caring what the value inside is?

Josh: Interesting, it's not `must_use`.

Amanieu: In most cases you want to treat it as `forget`.

Josh: If the inner value has drop it will be triggered. But I see what you mean.

Josh: Maybe we need 2 methods: into_inner when you care about the inner value and the other one to just dismiss the guard.

Amanieu: I disagree. We should have a method we dismiss the guard and as a side effect it gives you the value if you want to use it.

Josh: You don't thin kit would be valuable to have must_use on the value?

Amanieu: No, I don't think that would be valuable.

Josh: ok what do we call it?

Amanieu: We don't want wording that suggests you do want to always get the value out.

Josh: Agreed. `dismiss` covers it, `unguard` covers it.

Amanieu: `release` covers it.

Josh: `release` feels like a lock or reference count.

Josh: `unguard` would be my favorite, `dismiss` backup.

The 8472: When discussing the ACP we had a bunch of proposals and one of them was `undrop` and you said something about it being less metaphorical. And we didn't choose that less metaphorical one before.

Josh: You're saying undrop was even less metaphorical than unguard.

Josh: Should we set up a poll?

Amanieu: Can we do that next week?

Amanieu: I want to reply with the thing we have consensus on (disabling the guard).

Josh: +1. but with all the suggestions, can we pick one of the 2-3 things that feel like they fit now?

The 8472: `dismiss` and `disarm` are fine for me. I think the concern about it being too violent / guard person is very specific to certain contexts.

Josh: I'd prefer not `disarm` but I wouldn't object to `dismiss`

Amanieu: I have a preference for `dismiss`.

Josh: Then let's just go with `dismiss`

### (nominated) rust.tf/148656 *std: allow \`Condvar\` to be used with multiple \`Mutex\`es*

Amanieu: In parking-lot: a condvar can use with a single mutex at a time but it can be used with multiple mutexes over time. If a thread uses a mutex and it's waiting, no other thread can use it. This is useful for requeueing. If we allow multiple mutexes, it breaks requeueing. Our current implementation does not do requeueing.

Josh: The proposal here introduces an additional mutex separate from the inner mutex.

The 8472: Doesn't it introduce additional wake-ups? You need to wake the inner mutex first, then the user mutex.

Amanieu: That's only on pthreads. On other implementations it just works.

Josh: "the implementation change here makes it easier to switch the Mutex implementation independent of the Condvar one, which would e.g. simplify switching it to employ os_unfair_lock on macOS."

Josh: I think we should ask for an elaboration on the motivation. In particular what would make this difficult to make the switch on MacOs. Is it just that they don't want to have to enforce this restriction and you have to detect and enforce it?

The 8472: The requeueing you mentioned earlier, what's the benefit of it?

Amanieu: If you do a convar notify-all, if you don't have requeing you're waking up all the threads which go all back to sleep and block mutexes.

The8472: Doesn't it cause thundering heard?

Amanieu: Yeah, requeueing is designed to prevent thundering heard.

Josh: That does sound like something we want to add.

Amanieu: I think the motivation is just that it's not obvious to users that we don't enforce it.

Josh: You mean we don't check and panic at all?

Amanieu: On linux we don't use pthread.

Josh: So if you do this you're likely writing code that is not portable on macos?

Amanieu: and nonportable to a future implementation which will use requeueing.

The 8472: If we can make this cheaply then, we want this.

Josh: yes

Amanieu: If you lock a condvar, you store the address of the mutex you're waiting on. That's how it works in the parking lot.

Josh: The restriction is you can't use it with a different lock while someone is using it with a different lock?

Amanieu: Yes, while.

Josh: That doesn't match the restriction which says you can't do it over time.

Amanieu: Maybe pthreads is more strict.

Amanieu: "a condition variable must always be associated with a mutex"

Josh: I don't tihkn that's specifically saynig a particular mutx.

Amanieu: The posix spec says: "..."

Josh: Then if we enforce that restriction, is that also sufficient for queueing?

The 8472: Doesn't the futex have a count?

Amanieu: No. It has a counter that's incremented on every wake-up

The 8472: Doesn't it have a bit that's clear when it reaches 0 wake-ups?

Amanieu: No (talking about the futex on the condvar, not on the mutex)

The 8472: but if it's associated with a single mutex we can look inside the mutex

Amanieu: But how do we know how to release that

Josh: Unless we add an atomic reference. And even then it's difficult to avoid races.

... (Tomas's connection dropped)

Amanieu: We decided to not accept the PR. We want to keep the ability to requeue.

Amanieu: Okay, I guess that is our decision.

### (new change proposal) rust.tf/libs691 *\`std::io::Read\` provides byte\-order reading trait*

Josh: This is something many third-party libraries are popular for. Byteorder, Tokio's read implementation. Thisis asknig for reading 16,32 and 64-bit values in little endian and big endian order.

Amanieu: Counterproposal: a method to read an array of bytes which you can choose how convert those bytes to an integer

The 8472: We don't have methods on arry to get out endianness.

Amanieu: We have from_le_bytes and from_be_bytes

The 8472: What is the usecase of actually reading from Reader. If you're dealing with binary data, you'd read the whole thing into memory.

Josh: If you have a variable-length protocol, you read the amount of bytes you need

..

Josh: There are potentially a lot of individual lengths. It's also file formats.

Josh: To what Amanieu suggested: add a method that returns a const generic array by value and you pass the result of calling that to some particular interger::from_le_bytes (or from_be_bytes)?

Amanieu: Correct.

Josh: That method should exist. Some people may want to have a helper trait, but that trait would be implemented using this.

The 8472: I'm for the counter proposal.

Josh: I'd love to see those helper methods. But now I'm wondering whether the methods should be on read or blanket on Self::size. I think the array method should exist and we can decide if we want to have more past that but that should be simpler.

Josh: The exact proposal they've made seems like a bad idea. They're proposing `ReadLeOrder` and `ReadBeOrder` traits. I'd propose `read_u32_le` etc. Which iswhat Tokio and other helper provides.

The 8472: People will also want the native-endian version.

Josh: I can respond. Mention your proposal, then the helper methods later.

---

Josh: What should the method be called?

Josh: `read_array`?

Amanieu: `read_n`?

Amanieu: The only other one with the `n` suffix I can find is `splitn`. And `repeat_n`.

Amanieu: `IndexVec` has `from_fn_n`, `from_elem_n`. But that's compiler internals.

Josh: Any other proposals?

The 8472: `read_chunk`?

Amanieu: I like that. Chunk is always the read size anyway.

The 8472: Chunk isn't always compile-time sized.

Josh: It seems clearer to just say `read_array`. In practice it's going to look something like this:

u32::from_le_bytes(reader.read_array()?)
u32::from_le_bytes(reader.read_n()?)
u32::from_le_bytes(reader.read_chunk()?)
u32::from_le_bytes(reader.read_bytes()?)

Amanieu: `read_n` is just terrible now.

Josh: If you wrote `read_n::<N>` but that's unlikely to be written.

The 8472: If we add the array method we talked about it earlier:

reader.read_n::<4>().unsigned_be()

Josh: That's clever (in both senses). I had been imagining having this instead:

reader.read_array().to_u64_le()

Josh: And you know `N=8` because `to_u64_le` is only implemented for eight byte arrays.

Josh: I don't think we should add either one of these. I think we should add the `read_array` helper and individual helpers such as `read_u64_le` etc.

The 8472: That's a lot of clutter on the trait.

Josh: We can get them collapsed. And this is what Tokio has and in practice it has proven very helpful.

Josh: The `read_array` method doesn't need to be sealed. It wont' be in the trait methods because it will depuend on `N`. The `read_u64_le` can be in the trait which is why I propose we mark them as final.

Amanieu: Could we have "non overridable trait methods"? Where the default implementation can be provided, you can't impl them, but the default ??

Josh: I've written an RFC about this. It mentions it shouldn't necessarily need the trait to be dyn safe.

Josh: https://github.com/rust-lang/rfcs/pull/3678

Josh: Because you can't override these you can call ipmlementation on dyn trait.

Amanieu: because of that, the vtable now needs to include methods that weren't originally object safe.

Josh: I have a thing in the "future work" section that specifically calls out "you might want to omit final methods automatically, but sometimes you want ot include them in the vtable in case there's a specific optimization"

Amanieu: I really want this for the Error traits. Currently we have request_ref as free functions. I'd like these to be on the Error trait itself as final methods.

Josh: I think that's a great idea. Makes perfect sense and I agree.

Amanieu: I'm 100% in favour of this.

Josh: I've nominated it and started an FCP today.

Amanieu: I'd block stabilization of this until we get dyn trait stabilied out.

Josh: It's not a blocker.

Amanieu: This FCP is for lang experiment.

Josh: We can always make it better.

Amanieu: In my view that is the number one reason I want this for.

Josh: Other people need this for other things, there's multiple reasons.

The 8472: This sounds useful if you write methods that don't take the self type.

The 8472: So `read_array` was it?

Josh: `read_array` yeah.

### (new change proposal) rust.tf/libs683 *Expose \`FloatErrorKind\` from private \`core::num::dec2flt\` to public \`core::num::FloatErrorKind\`*

### (new change proposal) rust.tf/libs659 *Generalize ExactSizeIterator to QuantifiedIterator*

blocked

### (new change proposal) rust.tf/libs656 *implement Default for more iterators*

The 8472: Waiting for a reply from the author.

### (new change proposal) rust.tf/libs651 *ACP: Add API to write formatted data directly into a \`Vec\<u8\>\`*

The 8472: Skip, we're looking at a new Write trait.

### (new change proposal) rust.tf/libs647 *Add \`Waker::from\_fn\_ptr\`*

### (new change proposal) rust.tf/libs646 *ACP: Vec::remove\_ascending*

Amanieu: This is extract if and/or retain.

Josh: If extract_if could pass in a function and took the index, that would be a replacement for this.

The 8472: We've just stabilized this.

Josh: That's an argument for extract_if with an index. `extract_if_enumerated` or something.

Amanieu: Can we argue to close this?

Josh: What should peopl edo instead?

Amanieu: extract_if?

Josh: With the manual count of the index?

The 8472: People can hand-roll this themselves with unsafe. We could say "maybe? But too niche, write it in a crate?". They don't have to handroll it every time they need it.

Amanieu: remove_ascending also seems very niche.

Josh: `extract_if_enumerated` would be silghtly less niche. That'd be more straightforward. It would be less efficient than `remove_ascending` because that can skip ahead instead of calling the function on every element.

Josh: I agree, this is very niche. Also, it's doing it by index and I can easlily imagine taking an iterator of ranges.

The 8472: Can IndexMap do something like this?

Amanieu: In theory, yes.

Josh: If I was doing this I'd probably use BTreeMap

Josh: I'm convinced by the argument that this is sufficiently niche. We should say that they should try to implement this using the unsafe bits that they have.

Amanieu: Are we expecting to return the iterater of removed items?

The 8472: No.

Amanieu: One of the later proposals mentions returning an iterator.

The 8472: There are so many flavours of the mutating loops is that we can't implement them all.

Josh: The indexes thing can be common and the ranges things can for e.g. `Vec<u8>` for removing things from a large buffer like text. But we should let this percolate this in the community for a while.

The 8472 to reply

### (new change proposal) rust.tf/libs645 *\`Pow\` trait*

Amanieu: I'm inclined to reject. The argument is: "people have to rely on num-traits instead".

The 8472: I don't think adding the `Pow` trait wouldn't release everyone from the num-trait dependency.

Josh: I don't want to reject this out of hand. But we can say that we won't do this until we have inherent traits. Once we have that, I'd love to get through all the integer methods.

The 8472: I suspect if we add the entire zoo, our compiler times will explode.

Josh: The inherent traits should handle that. They won't have more resolution problems than the types themselves will have.

Josh: Proposal: defer until we have inherent traits and some trait item shadowing.

The 8472: And even then we need to look at a bigger picture not one method at a time.

Josh: Agreed.

### (new change proposal) rust.tf/libs644 *ACP: Visitor support for \`std::error::Error\` generic member access*

Amanieu: We only stabilised the backtrace method, right? No, we have a nightly `provide` via the `error_generic_member_access` feature. And that's still unstable.

Josh: Are they proposing removing the current API or augmenting it?

...

Josh: Changing. To a Visitor pattern.

Josh: Instead of us providing a request mechanism and using internally, `Request` would become a trait you pass in.

Amanieu: That seems much more complex. The current API example is half the size of the new API.

Josh: Response: we don't have `error_generic_member_access` and even if it did, this is wildly more complicated for the common case.

Amanieu: Programmerjake has an alternative proposal: https://github.com/rust-lang/libs-team/issues/644#issuecomment-3274760723

The 8472: I misunderstood, they're not proposing a recursion.

Josh: I read through programmerjake's idea and it's an implementation, it doesn't show how it's used. I don't know how it would feel.

Amanieu: You invoke a callback that returns a ControlFlow until it gets the value it wants. Meaning the callback can see every value. With the current API you only get one value.

The 8472: With the TypeIds you can organise the requests.

Josh: The difference here is instead of this being a trait, you're just passing a callback?

Amanieu: `RequestCallback` is a trait that takes a closure.

Josh: Proposal: we're concerned the proposal in this ACP would complicate the common cases of a simple error code or backtrace or similar field. Hypothetically, we want to see a design that doesn't make it really complicated. We also don't have a champion that owns the `error_generic_member_access`.

...

The 8472: If the error codes are copy rather than references, is there going to be a problem?

Josh: True.

Amanieu: Are we as a team happ ywith the current `provider` API?

Josh: I'd like us to see a ship to solve the problem it solves. We want a generic API for "this error has a backtrace or exit status". If the current proposeed API would solve the problem and obsoleting error APIs in the ecosystem including backtraces that would be great.

Josh: My inclination would be to ship what we currently have after a review.

Amanieu: People are asking for an API that lists all the provided types.

Amanieu: One of the issue is that if you're requesting a 100 pieces of state from the Error, you're scanning through the chain of providers a 100 times.

Josh: Yes, it's n^2. It's not a problem if you have a small amount of error types.

The 8472: I've seen different stuff in enterprise web frameworks with long chain of errors, reflections of errors etc. and that multiplies.

Josh: The question is whether that's the usecase we want to support with this API.

The 8472: It's there and they'll want to use it.

The 8472: Ideally you need to match the provider and the requestor side to do something like a hash map or two ordered arrays you can iterate in lockstep to get a good runtime behaviour. Even just one side providing a list would be an improvement.

Josh: I agree that if you have a bunch of properties, the ideal thing is to provide a list. But the common case will be a backtrace type, error code or similar. There the current API is n^2 in compiler time.

The 8472: This is on the tracking issue. Last time someone threw this on godbolt they found it wasn't optimised out.

Josh: If someone wants to take the whole thing and send it to opentelemetry etc. Let's assume we have an API designed for n=3 and not n=100, one of the items could be a property bag. You can then ask your

The 8472: The crate boundaries might complicate this. But if you have two HTTP middlewares and one forwards an error to another by wrapping the error, you need to look at each error in a chain. Looking at the cause. Each cause doesn't necessarily have such an open telemetry bag you're proposing. Then we need to fall back to looking at properties because a specific middleware might provide one specific property. And not one specific to your application.

Josh: Is it safe to say we're not comfortable approving this ACP? It makes the cases we do know about worse and the cases we don't understand we need more details on.

The 8472: I'd ask for it to provide a shorthand APIs to make the simple cases simple and provide the power where needed.

Amaniou: If we're going through dyn trait, this will have to invoke the callback n^2 times. With the existing API you need a single `dyn` call.

The 8472: Is this about the original proposal or programmerjake's one?

Josh: You're riht Amaniou that this proposal is providing a dyn that would have to be n^2. The `dyn` prevents the compiler from making any optimisations.

Amanieu: Today, you have one call into the Error vtable which provides a type ID. That's fine. The problem with a callback-based API is you're passing the callback in and then the thing is calling back for every piece of associated data in this error type. Two levels of function pointer calls.

Josh: The point fo this API is you do one pass to get all the things you want. It's O(n) not O(n^2). It's still bad.

The 8472: I did an approach where I passed an array of TypeIds and ??. In principle it could be optimized to run in the minimum of the steps. But that would require support in the compile time and it would get complicated.

Amanieu: Theres' a good chance that the implementation is not linear on the provider side.

Josh: It would be really nice if we could compile this to the equivalent of `.backtrace()`

Amanieu: it should already do that.

Josh: Oh, so only in the `dyn` case it doesn't.

The 8472: We should definitely check that. I'm not confident this is the case.

Amanieu: Josh, back to your two questions. First: are we happy with the way this API looks? The answer is no, we'd prefer for it to look more like what it does today.

Amanieu: The second question: What should the internal implementation look like?

Josh: Right. And right now we don't have anyone championing generic member access.

The 8472: I'm in favour of having a bulk get API as long as there's a simple way to keep the simple case simple.

The 8472:

> LLVM is unable to optimize multiple .provide_* calls into a switch table because each call fetches the type id from Erased::type_id separately each time and the compiler doesn't know that these calls all return the same value. This should be fixed. See Add provide_any module to core rfcs#3192 (comment) for one possible solution (although alternative solutions may be possible).

The 8472: This is a summary of someone trying to take over the generic member access work from Jane

Amanieu: This compiles down to switch in LLVM-ir and then to a binary search on godbolt.

### (new change proposal) rust.tf/libs643 *\`str::as\_str\` but for \`CStr\`, \`OsStr\`, \`Path\`, and \`\[T\]\`*

Amanieu: We added `str::as_str` so you can call `as_str` to a boxed string. This is asking to add these to `CStr`. Instead of having it on array, this method would be on slice and available for deref.

The 8472: Could we use the postfix `*` operator?

Josh: As soon as we have a postfix operator. Though we'll end up needing `.*.&` which is awkward.

The 8472: Shouldn't `.deref()` work?

Amanieu: That should work, yes.

The 8472: That seems like a better general solution.

Amanieu: Instead of putting `.as_slice` to everything that can deref on slice, we're just putting `as_slice` on the slice.

Josh: Similarly, for cstr.

Amanieu: We're not adding new methods, we're moving methods.

The 8472: Wouldn't just calling deref being even simpler?

Josh: Then it you'd have to call `.deref().deref()`

Josh: The reason for doing it this way is that you can go through multiple layers of indirections (box, arc etc.).

Josh: I think this makes perfect sense.

The 8472: Ideally, if you have a `Box<String>` and you want to deref it into `str`, you'd tell it to which type you want to deref. So you can stop in the middle of a deref chain for example.

Amanieu: When is `as_str` used?

The 8472: It's still unstable. The tracking issue has no FCP, no stabilization: https://github.com/rust-lang/rust/issues/130366

The 8472: It seems that's where the ACP is coming from.

Amanieu: I'm inclined to accept.

Josh: same thing. It's the same as the existing `str_as_str` with the same rationale.

Amanieu: I'm happy to have them under the same tracking issue because we're either stabilising all of them or none of them.

The 8472: I'm not opposed, it just feels as a workaround or something.

Amanieu: In general, you use as_str when the compiler isn't able to figure out what you meant.

The 8472: Okay.

Amanieu: Are you fine with having them in the same tracking issue?

The 8472: Cstr and osstr are used less often, but it's good to have them together to see the bigger picture. And we can always partially stabilise later if needed.

### (stalled change proposal) rust.tf/libs438 *ACP: \`ForwardInit\<'a, T\>\` to complement \`MaybeUninit\<T\>\`*

### (stalled change proposal) rust.tf/libs501 *ACP: Add floating point representation conversions*

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

Amanieu: Scott says we shouldn't make anything fundamental.

The 8472: What does it mean if a trait is fundamental?

Amanieu: You can implement it outside of its crates. It changes its coherence rules.

Josh: "But the rust orphan rule don't allow us `impl FromResidual<Option<T>>` for `Result<T,E>` out of std crate." -- yes, that's by design.

Josh: Given that the author of the `Try` and `FromResidual` traits says [we shouldn't do that](https://github.com/rust-lang/libs-team/issues/360#issuecomment-2526764922) and that the requestor is trying to do something we're pretty sure we don't want to do, we should close.

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

Amanieu: Is this get_disjoint_mut?

The 8472: The motivating example seems more complicated?

Amanieu: They can iterate over an index. The `iter_mut` lifetimes are not aligned with the lifetimes of the ??

Josh: It's effectively split_mut at every index array at once because it's an iterator. I was looking at the alternatives and made the assumption that `Splitting` is an iterator.

The 8472: The solution sketch has another iter_mut, what is it?

Amanieu: it's a chain of two iter_muts

Amanieu: The alternative seems worse.

Josh: It looks like they want multiple independent iterators over this and not look at the same element.

Amanieu: The best solution here should be get_disjoint_mut.

Josh: Sold.

Amanieu: There may be value for `split_item_mut`?

The 8472: The solution sketch has a trait

Josh: I don't think it should be a trait.

Amanieu: The last comment proposes `split_around` / `split_around_mut`.

Amanieu: It should be an inherent method on slices.

Josh:

impl [T] {
    pub fn split_around_mut(&mut self, i: usize) -> (&mut [T], &mut T, &mut [T]);
    pub fn split_around_mut_checked(&mut self, i: usize) -> Option<(&mut [T], &mut T, &mut [T])>;
}

Josh: Do we want to panic out of bounds?

Amanieu: What does `split_at`?

Josh: It panics.

Amanieu: We should panic.

The 8472: We have `split_first` which returns an option and there's no panicking variant.

The 8472: How much of an is this an improvement over splitting twice?

Amanieu: It's awkward.

Josh: It is awkward.

The 8472: It's just two lines.

Josh: A lot of our helpers are two lines.

Amanieu: As an optimization, we only need to do the bounds check once, not twice.

The 8472: Doesn't get_disjoint_mut accept ranges?

Josh: You can't give it a range_to, usize and range_from. The types need all to be the same.

Amanieu: And you'd have extra bounds checks.

Josh: At best, you could pass three range-inclusives, get three arrays in return and then unpack the middle one.

Amanieu: index must be strictly `< len` not `<= len`.

Josh: Do we want a non-mutable version as well?

The 8472: They're shared, you can split them easily. We shouldn't pre-emptively add it unless someone asks for it. If it panics I don't see the point.

Josh: You can just do two iterations over the thing.

### (stalled change proposal) rust.tf/libs452 *ACP: Implement \`TryFromIterator\<T\>\` trait to compliment \`FromIterator\<T\>\` trait.*

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

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

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

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

### (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)_