---
date: 2025-08-26
url: https://hackmd.io/nHuqSq6pTwiF8xlYXuURDQ
---

# Libs-API Meeting 2025-08-26

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, The 8472, David, Chris Denton, Lori (Rust Foundation director of outreach), Timothy Choi, Josh, Tomas

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/140808 *Implement Default for &Option* - (3 checkboxes left)
- merge rust.tf/143191 *Stabilize \`rwlock\_downgrade\` library feature* - (3 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/65816 *Tracking issue for \`vec\_into\_raw\_parts\`* - (3 checkboxes left)
- merge rust.tf/132968 *Tracking Issue for \`NonZero\<u\*\>::div\_ceil\`* - (3 checkboxes left)
- merge rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16* - (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/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/141994 *add Iterator::contains* - (3 checkboxes left)
- merge rust.tf/144091 *Stabilize \`new\_zeroed\_alloc\`* - (3 checkboxes left)
- merge rust.tf/63569 * Tracking issue for \`#!\[feature(maybe\_uninit\_slice)\]\`* - (3 checkboxes left)
- merge rust.tf/145656 *Stabilize s390x \`vector\` target feature and \`is\_s390x\_feature\_detected!\` macro* - (6 checkboxes left)
- close rust.tf/136638 *warn on empty precision* - (5 checkboxes left)

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

### (nominated) rust.tf/145628 *\[std\]\[BTree\] Fix behavior of \`::append\` to match documentation, \`::insert\`, and \`::extend\`*

Timothy Choi: If the left-hand-side and right-hand-side have the same key, `::insert` and `::extend` will replace only the value and not the key. `::append` will replace both and it should be consistent.

Josh: This is a behavior change, but I'd be shocked if anyone ever noticed.

Amanieu: This seems more correct than the previous behaviour.

Josh: I think we'd want the .. looks at the documentation.

Amanieu: We definitely want to do a crater run.

Josh: Yes. Unlikely this would find anything but yeah.

Amanieu+Josh: Sounds good.

Josh: We want to FCP it for Libs-API and ask for a block on a crater run and release notes. I'll tag it accordingly.

### (nominated) rust.tf/libs264 *Ability to stop child process from Inheriting Handles*

Chris: I think it's just like the unix one where you can pass some handles in and it would only inherit those. An empty list would mean no inheritance at all.

The 8472: We don't have that for linux.

Amanieu: There's an accepted ACP for this.

Chris: This would be Windows only.

Josh: It seems like both would be potentially useful: not inheriting any handles, the default as well as specific handles. How often do we expect people wanting to inheriting a specific handle vs. inheriting no handles.

Chris: How is it different is it to pass an empty list?

Josh: Depends on which is common. If inheriting nothing, then then a bool to disable inheritance may have better usability. But I don't know what the common case is.

Chris: We could put both on nightly and see what shakes out.

Josh: We should clear it in the nightly docs that we inherit by default and that we use this to limit inheritance.

Chris: I'd prefer we not inherit anything by default.

Josh: If we go with the new `Command` version, this could be added to the wishlist.

David: What's the current behaviour? Is there a reason to be able to inherit everything that's in there and add more handles to inherit?

David: I'm happy with either proposal.

Amanieu: We always set the inherit_handle flag to true. By default every handle that's marked as inheritable is inherited.

Amanieu: Does windows have support for renaming handles?

Josh: Strictly speaking unix doesn't have the ability to do that either, you just move them manually with fork before exec

Chris: No, there's nothing like that on windows.

Amanieu: Are people required to specify to mark their handles as inheritable before passing them to the method?

Josh: I'd not expect us to do that for them because if they've already done it it would be extra overhead.

Chris: When we create a handle ourselves they're not inheritable.

The 8472: So do the handles need to be marked as inheritable or not?

Josh: we could add a function to do this on Windows and tell people to call this method before.

Chris: We could also add an option to `OpenOptions` to make them inheritable when you create a handle.

Amanieu: I'd definitely expect the `OpenOptions` to be part of the ACP since it's kind of useless without it.

Chris: You can directly use the windows system api calls.

The 8472: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute

> These handles must be created as inheritable handles

Does this ??. Seems like it's not a great API for a multithreaded process. If one thread spawns a command in normal way (no inheritance) and another sets up inheritance then there's contamination of some child processes.

Chris: That's why I'd like Command to not inherit anythning by default.

The 8472: Adding this method would push people in the direction of having more inheritable handles.

Amanieu: I don't think it's a good argument. If people need more inheritable handles, they're still using it using explicit API calls.

The 8472: But we should still document this has non-local effects.

Chris: Sure.

Amanieu: I can reply to this one.

### (nominated) rust.tf/libs508 *impl\<A\> Allocator for &mut A*

Amanieu: There were people requesting support for this again. This is for a case where one allocator is given exclusively to a collection.

David: The most compelling rationale was writing a trait that has Allocator as a supertrait, and its own `&mut self` methods even though Allocator does not.

Amanieu: I'm open to accepting it. Any objections?

...

Amanieu: Ok, accepted.

### (nominated) rust.tf/libs628 *Implement some arithmetic operations for \`std::arch\` SIMD types*

Amanieu: We discussed this recentyl and accepted it. I still feel uncomfortable with this change. There are quite a few issues that were raised and I feel this is not the way we want to push people to long-term.

Amanieu: If you don't really care for explicit APIs, you should use portable-simd

David: Is there a smaller subset youd' be comfortable with or would you prefer to have none of them?

Amanieu: I'd prefer to have none of them. E.g. there's a xor command on AVX2 but no AVX. So you call the operator and it would silently be only performant on AVX2

Josh: While there is an operation to map it to, if there's an operator masking it, people might not know that they're introducing an explicit dependency on the platforms that have them?

Amanieu: Yes. The code will still work, but it's a performance footgun.

Josh: In theory we could introduce that same warning on operators.

The 8472: Does this inteeract with target features? E.g. if you used an addition in a target_feature method. If you call the trait method does it inherit it from the calling feature's context due to inlining or not?

The 8472: The PR has no codegen tests so it's not obvious what happens there.

Amanieu: I suspect it does what you'd expect. Doesn't MIR do inlining from bottom-up (from inner-most function to the outer-most)?

The 8472: I think that's the LLVM inliner. I think MIR does the top-down. But I'm not sure.

Josh: Is this tangent likely to be productive one? Will it substantially change your thoughts on doing this?

Amanieu: Yeah you're right, I don't think it matters.

Josh: Is this a blocking objection from you or a concern you want to discuss further?

Amanieu: Blocking objection. I think this is going to be a mistake we're going to regret in the future.

Josh: IS your expectation that thorugh som ecombination of traits or similar, people would be able to use the portable-simd generic types with native platform intrinsics?

Amanieu: Today it would require into (which is zero cost).

Josh: Sure, but that's going to create a lot of pain. E.g. I've written this code using non-portable simd for X86 and ARM and I'd add the multiply method to use the same algorithm. If you want to have convert to portable-simd: convert to portable-simd, then do the operations, then convert back that's a big usability hit.

Amanieu: So you still think we should go forwad with this?

Josh: I personally do. But I wouldn't have any concerns adding caveats to only add featuers that don't require more than the baseline operatior?

Amanieu: The type itself doesn't have a target feature, only the intrinsic do.

Josh: I'm talking about the fact that if you're using the 256 types, you've enabled avx.

Amanieu: But all the integer types are AVX2 operations. To be fair those do use separate types.

Josh: Alternative suggestion: I think your footgun is reasonable. It would be reasonable to tell the folks doing this ACP to say we're looking for the usability improvement but only when that would keep sensible performance and raise a warning otherwise.

Amanieu: You'd have to get a post monomorphization error.

Josh: It would be a post-mono warning which seems more reasonable. And in lot of cases there would be no monomorphisation because it would be a concrete method on a concrete type.

Josh: Would some reasonable set of warnings ameliorate the concerns here?

Amanieu: I suppose if we had warnings, it would aleviate my concerns.

Josh: FWIW the absence of warnings I have concers with too.

Amanieu: Should we also support integers that don't have intrinsics? I think the answer is no.

Josh: I agree. I can write it up and you can say whether that addresses your concerns or we can edit it later.

Amanieu: Thanks.

### (nominated) rust.tf/138879 *Ensure non\-empty buffers for large vectored I/O*

FCP finished. Should be merged?

Chris: Trevor Gross doesn't seem to be too enthusiastic. This a situation that seems to indicate a problem somewhere else.

The 8472: I raised the motivation question some months ago and there was no reply.

Amanieu: Why is it talking about super let? .. it uses super let but it's in an internal macro, it doesn't matter. That's not an API concern, ok.

The 8472: If you're using vectored write/read operators you have to deal with short reads/writes and you need to process the buffer and should be calling advance_slices. So I'm wondering under which scenario is the user using the API correctly but still needs this change.

Amanieu: It's not just a short read. It's a short read length of 0 which typically indicates end of file.

The 8472: Only if you didn't truncate. If you already have logic to deal with short reads and advancing the slices as needed, then you're also handling this case and you can't run into this condition unless you pass a lot of empty buffers somehow?

Amanieu: I can imagine a situation where you're constructing something manually with many pieces and the first 50 cases are empty.

The 8472: I want to see a usecase where this is needed.

Amanieu: If it returns 0 that's an empty read. End of file, which is not correct.

The 8472: I think this is a documentation issue -- we're not describing the underlying API. The platform API says you get an empty result either if it's end of file or if you passed an empty buffer.

Amanieu: Expect the user didn't pass an empty buffer. We passed a subset buffer and it happened to be empty. It's trivial for us to fix it.

The 8472: By looping in a loop.

Amanieu: If you're doing it yourself you'd never get to this case.

Josh: Doc improvements would make sense. But if you're concerned if this is N^2 if it's done in the loop, then the today it's N^2 in the OS too. So I don't think the loop is a problem in practice that changes the performance characteristics.

The 8472: Yes, the OS loops over the items, but if the userspace calls them correctly, they're never empty.

Josh: I agree, but what I'm saying it is if we do that, this also doesn't cause issues.

The 8472: I want us to do better than that. It should only happen in practice when the user does something wrong and we should not paper over that.

Josh: I can think of a use case fro having a list of iovecs some of which are empty. But I can't think of such a list where you don't know which ones are empty -- and in that case you should not passing them in.

Amanieu: I can think of usecases that could theoretically extend to arbitrary size.

The 8472: Can you post these to the issue? I've asked for use cases that aren't just the user calling this API incorrectly.

Amanieu: I still strongly think we should accept this.

The 8472: If you have examples, please post them to the issue.

Amanieu: Even without examples I don't think we should be exposing IOV_MAX.

The 8472: Maybe but we definitely also should update the documentation. The `advance_slices` is not well advertised. And we're not showing users how to call this in the loop correctly.

Josh: This is not a single conditional in the common case. Its zero conditionals in the common case. The compiler should notice that it can inline tihs and completely eliminate the test.

Josh: I wonder if we should do some amount of documentation on read vec being optimized out. In that case this is a good thing to have.

The 8472: If you're calling this in the loop and don't have have ??

Amanieu: But even then the overhead is tiny compared to the cost of a system call.

The 8472: But it's incorrect.

Amanieu: It is correct, just not optimally implemented.

The 8472: If you're not doing advance_slices that indicates you have a bug where you're not dealing with short writes correctly.

Amanieu: I still strongly think we should just accept this.

The 8472: Yeah, and we also need to fix the documentation.

Amanieu: I think we should just improve the documentation and not change anything.

### (nominated) rust.tf/141727 *Tracking Issue for NUL\-terminated file names with \`#\[track\_caller\]\`*

Amanieu: People are having complaints about the name of the method. `file_with_null` could be `file_as_cstr`.

The 8472: What exactly is the concern?

> The existing std usage of x_with_nul consistently refers to "raw" nul-terminated &[u8]/`Vec<u8>`s. For example, CStr::to_bytes_with_nul returns a &[u8] and CString::from_vec_with_nul takes a `Vec<u8>`. A CStr or CString is not referred to as "x_with_nul".

It would be more consistent to call this `file_as_cstr` or `file_c_str`

David: That would make sense to me.

Amanieu: any thougts on renaming it to `file_as_cstr`?

The 8472: This is a pretty niche function. I don't tihkn it really matters.

David: What is the next call after this line? After that they're calling `as_bytes` etc. so if that doesn't include the null, that would be misleading.

The 8472: That's what as_bytes on the cstr does. It just seems redundant with what the signature says but whatever.

Amanieu: The next call after this line is probably `as_ptr`.

David: I have a weak preference for the current name.

Amanieu: Me too. Even if it's slightly inconsistent, it clearly indicates why you would use this.

David: It would be nice if we were consistent in the standard library with when we deal with cstr.

Amanieu: Oh no we have `into_c_string` and `into_cstring`. I think the underscore's more correct. They're two separate words: "C String".

David: Yeah the worst thing is we have literally the same method name with and without underscore.

Amanieu: I think that's worth fixing with a deprecation.

The 8472: Is it worth fixing this? One is an error code that almost nobody uses.

David: Let's count that as another argument in favor of `_null`. Since it's not clear where underscore sholud go.

Amanieu: I think it's orthogonal. But there's enough arguments for `with_null`. There's also a proposal ot relax the lifetime and we should definitely do that.

The 8472: The lifetime has already been fixed. Looks like the tracking issue wasn't updated?

David: What is the next step here? Do we leave this as a comment or do we need to restart the FCP?

Amanieu: It's in the final comment period now. Let me copy the concern. If we're already resolving the concern in this meeting, do we need to have the concern?

The 8472: Othe people not here may have an opinion?

Amanieu: The only people not in this meeting are Mara and BurntSushi (and Josh and TC but we discussed this two weeks ago).

Amanieu: I can reply we've discussed this. That we're happy to keep `file_with_null` because it's clearer with what it actually provides. If anyone has concerns they can reply there.

The 8472: Cstr also makes it clear it provides the null at the end. Both are fine from the correctness angle. It's so niche you don't really have to care about it in the first place.

Amanieu: I can just reply to the issue.

...

Amanieu: Now I'm writing it up I have a preference to cstr. If we stabilize `file_with_nul` we may regret it later. If we stabilize `file_as_c_str` I feel we may regret it less.

David: I still prefer the current name and I can write the comment if you'd prefer.

The 8472: I don't thin we need the `_as` this isn't the conversion, just getting the data out.

David: I agree, `file_cstr` is also reasonable.

Amanieu: I think that `as` makes it clearer.

Amanieu: I'd still go with the rename to `file_as_c_str`.

Amanieu: I can cancel this FCP and propose a new one.

David: Ok.

### (nominated) rust.tf/144506 *introduce the Comparable trait for btree internals*

Amanieu: It doesn't introduces any public API. It just adds the `Comparable` trait. Equivalent trait to HashBrow and IndexMap. Rather than using the Borrow trait, you can specify arbitrary types that are comparable with the key.

The 8472: And there's a blanket for `Borrow` for backwards compatibility.

Amanieu: I don't think ther's point in accepting tihs unless we make a public API change. Are we willing to make the API change to introduce these traits?

The 8472: People asked for this several times I think? But someone would still have to write an ACP. Do we then also want it for HashMap?

Amanieu: Yes.

Amanieu: Is this the right API? These traits provide a lot of flexibility. But sometimes what you need is just being able to hash your keys yourself.

The 8472: There's always the intermediate abstraction level -- you don't always need the most low level.

Amanieu: I talked to this person and I think they may be better served by converting their key to integers and combining them to i64 and use that directly as a key.

Amanieu: This doesn't have any state. If you just want some indices in the map that point to soem infrastructure outside of the map.

David: Alternative: have something like `get_by` that you pass a closure that would do the conversion.

Amanieu: That's not practical because of the sheer amount of methods in ordering.

Amanieu: BTreeMap has safety guarantees where the keys must always be in order. If you expose raw hashing, you can end up with keys that can't be reached. So I don't think we can expose this directly.

David: Regarding the set of methods being too large -- this could be just on Entry or something similar. If you can get an entry by a comparisson method would be good. I've wanted this kind of API fairly frequently. In the context of collections that have a pair of keys.

Amanieu: Is that just using tuples or using explicit types?

David: Thats' part of the point of the API. You make a local type, then you implement your comparable to e.g. (str, str).

Amanieu: If we had this in the standard library, could we implement this for tuples?

Amanieu: Just because you'd be able to have blanket implementation in the standard library it should just work, you wouldn't have to provide your types. I think that on its own is enough to bring in those two traits.

David: What about your concerns?

Amanieu: Those don't apply here. We're not duplicating the methods. This is only used during lookups and when you're inserting, you're comparing the actual key you're inserting with the elements. This is only used for read-only operations. When you're inserting, you're providing the actual key.

Amanieu: I'm happy to accept this PR but make the traits public and also use them for `HashMap`.

The 8472: But we can stabilize them later so we don't have to make them instastable.

The 8472: Can it cause inference failures?

Amanieu: No, it shouldn't.

Amanieu: I can write-up a comment.

David: We should not accept this PR as is. These types are `pub(crate)` so the bounds are invisible.

Amanieu: No it also changes the bounds only to internal methods. I think this is more meant as a proof of concept?

David: How is the PR author planning on using this?

Amanieu: The intent is to make this public and this is a proof of concept.

The 8472: The PR top comment links to another comment in index_map.rs where he describes the usecase.

David: I read that but I don't see how this PR would be the right step. This is making things more complicated internally in a way that's not observable.

The 8472: Would this conflict with adding a comparison function to Map itself?

Amanieu: The problem with that is that it would need an extra generic argument.

The 8472: Which defaults to something that uses Eq and ??.

Amanieu: I think it would not conflict but I'm not sure.

The 8472: I guess the function would have to take a borrow so it can't take K anyway so it may as well take Comparable?

Amanieu: I'd love to have feedback from Josh Stone from the crates ecosystem.

Amanieu: I'll propose to add this as a nightly featuer.

### (nominated) rust.tf/145335 *Move WTF\-8 code from std into core and alloc*

Chris: The actual ask is to add `Debug` implementation.

Amanieu: We don't have debug for `EncodeWide`? We had a discussion about this.

Chris: The debug implementation here is just very basic.

Amanieu: Found this recent FCP: https://github.com/rust-lang/rust/pull/140153

Amanieu: We already have an accepted FCP. The FCP is waiting-on-review.

The 8472: Debug is unstable, it should be fine.

Amanieu: I'll reply to this.

The 8472: This one doesn't need any FCP since the other one already covers it?

Amanieu: Yeah.

### (nominated) rust.tf/145610 *Stabilize \`char\_max\_len\`*

Amanieu: We're not sure whether we only want the associated constants or also the freestanding constants under the `char` module.

The 8472: We haven't deprecated the module and it contains a bunch of stuff.

Amanieu: And `std::char::MAX` it's not deprecated.

The 8472: So it makes sense to keep it. Althoug the docs say to use `char::MAX`.

Amanieu: I'll start an FCP on only stabilizing the associated constants.

The 8472: We already don't have `MIN` in the `std::char` module so it's already neglected.

### (nominated) rust.tf/145664 `P-lang-drag-1` *Stabilize \`std::panic::Location::file\_with\_nul\`*

### (nominated) rust.tf/145722 *implement Extend\<{Group, Literal, Punct, Ident}\> for TokenStream*

David: I'm checking if this exists in `proc_macro` already.

David: That seems fine to me.

Amanieu: Is it in `proc_macro` too?

David: It's not.

Amanieu: Basically those things convert into TokenTrees. David, do you want to start FCP on that one?

David: Ok.

The 8472: does it not have a From impl? ... It does. Maybe more general would be Extend for any item type that has an ipml for TokenTree?

Amanieu: That may be too much?

The 8472: The only one would be iterator of token tree?

David: You'd also have the proc_macro token tree which you don't want.

The 8472: Okay, you're the expert.

### (nominated) rust.tf/145784 *\`pin!()\` changed temporary lifetime extension behavior in version 1.88.0 with edition 2024 tail expression temporary scopes*

The 8472: Mara already checked the second box. And was the first one asking ... Ok so it changes pinning in what way?

Amanieu: AFAICT it's also a compiler chaneg not just library change.

The 8472: I think this is tagged Libs because it contains the pin macro.

Amanieu: I'm struggling to understand this one. Would it help to leave it for next week when maybe someone from Lang could explain the context?

The 8472: It would help.

Amanieu: I'm inclided to leave it for next week.

The 8472: There was some urgency for the backfix.

Amanieu: Having Mara's okay is good for us. I'm happy to just nominate.

The 8472: It's quite sketchy that lang changes the behaviour of macros but I hope they know what they're doing.

Amanieu: Me too.

### (nominated) rust.tf/145838 `P-lang-drag-1` *don't apply temporary lifetime extension rules to non\-extended \`super let\`*

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

(waiting on Lang)

### (new change proposal) rust.tf/libs642 *ACP: add funnel shifts*

Amanieu: It's like a rotate except wider. You can concatenate two integers and do rotate on that to extract some bits from that and some bits from the other. It has codegen benefits. The intrinsics are fine.

Amanieu: Would we want a wrapping version?

The 8472: Isn't this wrapping? You mean for the shift amount?

Amanieu: Yes, the shift amount.

The 8472: What do the CPUs do normally?

The 8472: The shift value is taking modulo bits so it's already wrapping.

The 8472: Our rotates are already wrapping.

Amanieu: But rotates you can rotate indefinitely.

The 8472: IF this is effectively a rotate, is funnel_shift the right name?

Amanieu: Yeah, funnel_shift is the right name for the operation.

The 8472: Correct why? Everyone does it? Where does the name come from?

Amanieu: It's used by some CPU instructions -- they call it funnel shift.

David: Reminds me of the widening operations where you start with a u32 and come back with two u32s. Here you start with two u32s and come back with one.

Amanieu: The modulo is a bit strange. If it actually rotated, that would make sense. But funnel shift we'd want a wrapping version. Given that I think we should error out on it.

David: Does that mean we're now adding checked/saturating/etc. funnel shifts?

Amanieu: No. I'd just do wrapped_funnel_shift

The 8472: Coming back to my CPU question, what does it do?

Amanieu: It does double shift left / rigt?

The 8472: And how do they behave?

Amanieu: They're both wrapping on x86. An ARM it has an extract instruction that takes two registers and the shift is immediate so that has to be within range.

The 8472: Do users ever feed runtime values into that or is it usually const amount?

Amanieu: No idea. I think it's used for some BSP algorithms.

The 8472: If people are using it and GPUs have it, then yeah. Godbolt is rather convincing that it improves codegen.

Amanieu: I can reply except that we may want to have a checked version of this?

### (new change proposal) rust.tf/libs641 *BorrowedFd view types*

The 8472: Josh asked me to write it up last week.

Amanieu: What does FdView actually do?

The 8472: We'd implement the trait on File, unix sockets etc. That it's safe to temporarily create a reference to a different type that we can use its methods. You can turn a reference of a socket to a reference of a file etc.

The 8472: Since everything is a file and everything operates on FDs, our wrapper types are more of a hint that you're working on a TCPStream rather than a Socket but sometimes you want to do the conversion.

Amanieu: The issue here is that it's generic. You'll always have to turbofish this.

The 8472: Turbofish or assign to a local where yo specify a type.

Amanieu: In practice you'll always want to use this for single methods at a time. Given that I think it would be better to have as_file, as_socket etc.

The 8472: This is an n-n relationship and users should be able to implemetn their own.

Amanieu: I think that's better from the usability ponit of view. And people can use extension traits if they want to do their own stuff.

The 8472: The point is BorrowedFd and OwnedFd are universal types and that's what we're trying to do here. You also have the Tokio socket types and so on. Limiting this just to the standard library would not be worth it.

Amanieu: But the usability is an issue. You'd always have to turbofish it.

The 8472: Yes, but you have to always specify the types. And you'd have to always enumerate all the types with your proposal.

*Amanieu reads out like 5-6 different types* I see

The 8472: And there's more coming.

Amanieu: Good point, there's a lot of stuff.

The 8472: Also look at the alternatives that could make it more flexible than the base proposal that uses `repr(transparent)`.

Amanieu: I prefer `repr(transparent)`. I think I like the original proposal. Leave it as is.

(meeting ended here)

### (new change proposal) rust.tf/libs640 *Add \`{UniqueRc, UniqueArc}::into\_pin\`*

### (new change proposal) rust.tf/libs639 *Remove unwrap noise from idiomatic lock poison propagation*

### (new change proposal) rust.tf/libs638 *Add memory prefetching to \`core::hint\`*

### (new change proposal) rust.tf/libs634 *ACP: Exact file read at offset on Windows*

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

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

### (new change proposal) rust.tf/libs568 *Implement \`Read\` and \`Write\` traits for \`BorrowedFd\` and \`OwnedFd\`*

### (new change proposal) rust.tf/libs553 *Add a "shrink\-if\-excessive" API to \`Vec\`*

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

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

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

### (stalled change proposal) rust.tf/libs133 *Add fmt::Write to io::Write adapter*

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

### (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/libs111 *Restructure ptr\_metadata to minimal support*

### (stalled change proposal) rust.tf/libs457 *APC: split\_pattern on slices*

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

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