---
date: 2025-06-10
url: https://hackmd.io/QaVM_zJiQt-ABX8HP-vaAQ
---

# Libs-API Meeting 2025-06-10

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

(rfcbot.rs is down so this list is empty today)

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

Amanieu: discussed yesterday, no need to do it today.

### (nominated) rust.tf/133724 *Tracking Issue for \`breakpoint\` feature (\`core::arch::breakpoint\`)*

FCP finished. Should be merged?

Josh: Summarized in https://github.com/rust-lang/rust/issues/133724#issuecomment-2936119660. Some concen from someone, but they didn't want more bikeshedding.

Amanieu: Should we stabilize this?

Josh: Let's stabilize. Stabilization PR, then?

Amanieu: Nominate the PR for lang.

### (nominated) rust.tf/135178 *Document the behaviour of RUST\_MIN\_STACK=0*

Amanieu: We have a RUST_MIN_STACK variable that's set for setting stack size. If you set it to 0 you set it to the platform default rather than Rust's default of 2MiB

Chris: Seems that should be documented.

Amanieu: Do we want to keep this behaviour?

David: As opposed to the behaviour where main would immediately overflow the stack?

Amanieu: If we document this, we're permanently saying that the `0` uses the platform default rather than Rust. Only for new threads.

Josh: Fine to document, but we shouldn't be specifically sayng that Windows defaults to 1MiB stacks.

The 8472: Don't we normally use less implicit option handling (at least in the compiler). Do we need a string to be past instead of a metric value?

Amanieu: I like that better.

The 8472: If we switch to that, given this isn't documented, we could switch to it while leaving this as is.

Josh: If we're going to have this behaviour available in Rust code, it should be more of an option rather than a numeric value.

Chris: What does the stack-size (on the builder) function do if you pass in 0?

Amanieu: It sets the stack_size to 0 which will fail during the thread creation.

Amanieu: Using the stack_size method does use speficic behaviour. Should be documented.

Amanieu: Some people are already using `RUST_MIN_STACK=0`

The 8472: That means they're using an implementation detail?

Amanieu: It's explicitly allowed, just not documented.

*Amanieu reads the code*

Amanieu: Unix implementations increase the size to the minimal stack size for that target (which is `p_thread_min_size`?) if the value is lower. The documentation just seems wrong.

Amanieu: On Windows it uses the default size for the executable.

Amanieu: On Linux we round it up to the minimum stack size (60KiB).

Josh: Can you post a summary to what you just found to the thread?

Amanieu: Will run a few tests and look into it more. And post an update.

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

Waiting on the lang team.

### (waiting on team) rust.tf/141996 *Fix \`proc\_macro::Ident\`'s handling of \`$crate\`*

David: This changes the meening of Ident::new -- it now accepts "$crate" and turns it into the same ident that you'd use in a `macro_rules!` macro.

Amanieu: Is it an identifier though?

David: If you use `macro_rules!` macro and pass `"$crate"` it'll work -- it's not treating it as two tokens. Though interestingly, you can add a comment between `$` and `crate`.

David: Within the same crate it'll be an empty string, in another crate it'll be the crate's dependency ??

David: It still counts as an identifier even if it's part of the path. You'll get `::crate_name`

Amanieu: Still weird this is an identifier even though it technically isn't one.

David: It even expands to an empty string or `::crate_name`

Josh: Does it expand to an empty string or `crate` (the literal word "crate")

David: Not sure, maybe depends on the edition?

Amanieu: Do we want this be done via the `Ident::new` constructor or have a separate method (`dollar_crate`?)

David: Ideally, in Cargo.toml you can declare not just dev/build dependencies but also macro dependencies.

David: Currently you work around not having such a contstructor is you take an attribute macro, take a macro_rules macro and pass the attribute through a side channel

David: `$crate` doesn't fit well in `Ident::new` -- should be the other constructor.

Josh: Accepting `$crate` in `Ident::new` sounds good now and we can add the other behaviour later. We could add a method that takes an `Option` of a crate name.

David: Recommend approving this PR.

David to propose FCP

### (new change proposal) rust.tf/libs601 *ACP: Safe conversions between arrays and \`std::arch\` vector register types*

Josh: Seems pretty reasonable. Proposes impls for array of bytes and platform specific types.

The 8472: Except for endiann-ness?

Josh: These are all platform-specific types -- should have a defined endianness.

Amanieu: Not on ARM. On big-endian ARM the layout of the vector types is inverted. https://llvm.org/docs/BigEndianNEON.html

Amanieu: Inclined to accept. Should this use the memory order (the first element is the highest byte in memory) or the element order?

Josh: If the register has a concept of "this is element 0, 1, 2..." then this should load the element 0 from the index 0. You should have indexing match between the two.

The 8472: But they're using transmute so they're using the memory order, aren't they?

Amanieu: ARM specifies that the memory order on big endian: if you have a vector of 16 u8, the element 0 is at the highest byte in memory. If you load the vector as a single load it gets byte swap. But if you load it as 64 bit order, it doesn't get swapped.

Josh: We can have `to_ne_bytes`, `to_ne_u16` etc. family of methods.

*it's cursed, this is why we don't use big-endian anymore*

Josh: Other than big-endian can we assume that memory and elemnet order are the same?

Amanieu: Don't know about other platforms. Don't know what powerpc does.

Josh: This does seem like a notable blocker. If you do this via memory order, you can work with something in memory as an array or read it out as type and get the same order. As an element order, you can get make some algorithms easier, but if the two things are different, that can be confusing.

Josh: Was going to propose to implement this for the SIMD taht are not cursed. But that wouldn't work for ARM at all (we have the same impl for ARM and ARM64).

Amanieu: A counter proposal: we should have safe versions of all the load intrinsics. The load intrinsics specify how the bytes of the elements map in the register.

The 8472: The discussion mentioned that a partial stabilisation of `portable_simd` might work.

Josh: Why don't we respond to this that endienness (in particular on some targets) is a big concern.

Amanieu: I'll reply to this one.

### (new change proposal) rust.tf/libs599 *More \`AsyncIterator\` helper functions*

Amanieu: Should we just nominate this for async?

Consensus: yes.

***

TC: A lot of overlap with 594. It's even less likely that we're going to accept this ACP at the moment. Too many questions on async iterator/stream etc. Don't have appetite on iterating on this now. We can close it.

Amanieu: Yes.

### (new change proposal) rust.tf/libs598 *ACP: Add \`{u8,u16,u32,u64,u128,usize}::bit\_len\`*

Amanieu: Isn't this ilog2?

Josh: It's ilog2+1 unless it's zero (leading zeros subtracted from the width of the type).

Josh: How common is this?

Amanieu: Quite often when I do instruction coding, I have a helper `fits_in_bits` method -- can I make this number fin in 8-bit bitfield?

David: Not clear to me that `bit_len` makes it more clear than `u64::BITS - leading_zeros()`

Amanieu: It is quite common.

The 8472: Isn't it just the naming issue? If we can't fit the leading zeros it's the least significant one?

Amanieu: There are some belated ACPs: #397 and #467.

https://github.com/rust-lang/libs-team/issues/397
https://github.com/rust-lang/libs-team/issues/467

Josh: #397 special cases 0 which would normally fall out as far as I could tell.

Josh: Do we think the helper method is useful? If so what do we call it?

Amanieu: C & C++ have added bit_width, bit_floor and bit_ceil

Josh: What's bit_floor

Amanieu: bit_floor is previous power of two and bit_ceil is the next power of two.

Josh: We have next power of two.

Amanieu: Should we accept 397 instead? `bit_width` and `prev_power_of_two`.

Josh: Seems fine. That naming is good, accepting this as is sounds good.

The 8472: People are bikeshedding the name there too.

Josh: `prev_power_of_two` doesn't need bikeshedding -- we already have `next_power_of_two`.

Amanieu: It has interesting behaviour around `0` and `1`.

Josh: It's "next/prev or equal power of two"

David: "next power of two" I'd expect debug would panic and release would wrap to 0.

The 8472: I don't like the `bit_width` name. If you display the binary representation and trim all the zeros except for the last one, you'd get

Josh: The number of digits to store 0 bits is 0. The number of digits to display 0 is 1. The display version of this dosen't seem like the primary reason people would be looking for this helper for.

David: Does this point also apply to `bit_len` or also to `bit_width`?

The 8472: Not sure.

Amanieu: I think every other language uses bit length or bit width.

Josh: Mild preference towards `bit_width`. Length seems a little bit odd intuitively (but everyone's intuition differs).

Amanieu: We apparently already have "previous power of two". We call it "isolate_most_significant_one". Unstable, effectively the same as previous power of two.

https://doc.rust-lang.org/std/primitive.i8.html#method.isolate_most_significant_one

Merged in Feb/March 2025.

The 8472: It was one of the ACPs mentioned earlier.

David: Not sure it's the same behaviour. There's no debug mode catching in this one around `0`. Might still make sense to add `prev_power_of_two` to catch it in debug mode.

Amanieu: Conclusion: let's just do `bit_width`? And ask if "previous_power_of_two" is acceptable.

Amanieu: I'll accept 598 and ask in 397 if previous_power_of_two is acceptable.

### (new change proposal) rust.tf/libs597 *Add trim\_prefix and trim\_suffix methods to str*

Amanieu: Discussed last week. Based on that discussion people seem to prefer `trim_prefix/suffix` (as originally proposed)

Amanieu: Are we happy to accept that (I'm okay with it).

TC+David: That's fine.

Accepted.

### (new change proposal) rust.tf/libs594 *Add more helpers for \`Future\`*

Amanieu: Still async nominated. There's been some pushback from some people.

Amanieu: Shall we leave it till the async comes back to us?

TC: We've opened a thread on zulip, discussing it.

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

Amanieu: Will follow up -- needs discussion.

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

Josh: Doesn't seem anything changed since the previous summary from last week. Proposer has not responded yet.

Amanieu: Waiting on author.

### (new change proposal) rust.tf/libs585 *ACP: efficient runtime checking of multiple target features*

Josh: We responded to this. The only response was someone asking why we'd want or and not just that?

Amanieu: Mark this as `ACP-accepted`.

Josh: Yes and ask them to implement the PR.

### (new change proposal) rust.tf/libs584 *\`From\<PipeReader\> for File\` and \`From\<PipeWriter\> for File\`*

The 8472: Reject this.

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

Josh: I remember this coming up previously. Recall there being bikeshedding whether it should be `hash_map!` or just `map!` and discussion related more generic solutions.

Amanieu: The previous meeting notes said: "Defer to next meeting" ;-)

Josh: Accept as is and deal with the generic solution later on?

Amanieu: Hesitant about `map!` macro -- could confuse with the `map` method on many types.

Josh: But that's not the (original) proposal.

Amanieu: bikeshed: arrow or colon?

Josh: How hard would it be to say "both"?

Amanieu: Are you allowed to have that after an `expr`. Could be treated as type ascription.

Josh: We killed type ascription, but are macros lagging behind?

Amanieu: We can't follow an expr with a colon.

David: It is implementable (serde json! macro does it), but it's far more complex.

David: We munch until the colon and then parse everything after the colon as an expression.

Josh: Seems like an argument towards the current (arrow) syntax.

Amanieu: Can we fix this (taking colon after expr) at the language level?

Josh: Can we do this after edition.

Amanieu: Would it be a breaking change to allow more stuff?

Josh: If expr can't allow colon, that should be fine.

TC: Maybe not the case here, if we're talking about follow set behavior, but in general, it is a breaking change for a macro matcher to accept more than it does now, as it visibly changes what hits the fallback case.

David: It doesn't fall to the next macro after the next colon. It isn't a breaking change here.

Josh: It's not a breaking change if ?? We'd have to check that.

Josh: Do we want to accept colon exclusively or do we want to accept arrow now and possibly accept colon later?

The 8472: Not sure either colon or arrow is great. Breaking up values into multiple lines would look really weird with both.

Josh: For that we could just use `HashMap::from`. The point here is to have a concise syntax when you don't want that.

Josh: When you want to make it more complicated and do want to use macro, don't parenthesise work here? You can paretthesise the key and parenthesise the value.

Amanieu: I like the colon syntax because it matches the debug output.

Amanieu: I like it as the only option. We should pick one and stick to it.

TC: On the lang side we have had some unhappiness with using colons for struct initialisation. And we did talk about using `=` over an edition. Everywhere else in Rust it either has an ascriptive meaning or type meaning.

Amanieu: Some of the examples use string literals but you'll want to use owned strings.

The 8472: That's what I was saying. Once you start constructing a more complex stuff, this will end up very cluttered. We'd need to see more complex examples to see if this is really an improvement.

Amanieu: Something like s-strings might be a solution.

The 8472: But that only solves it for a string.

Josh: If you're writing a trivial map it'd be nice to have a shorthand for it.

The 8472: In those cases it looks fine but you'll quickly fall off the nice path.

Josh: Feel like this is designed for the simple case and that seems ok.

Josh: Does anyone have an objection to having a macro for this at all?

Amanieu: I think it's a good idea to have something like this.

Josh: Now the syntax?

Amanieu: Preference for colon. But that's blocked on lang. I'll veto doing both.

The 8472: I like the parantheses approach. Very thin abstraction over the already known syntax.

Josh: I don't think we should bother if we're not doing a new syntax. The point of this is writing a syntax that looks more evocative of a map.

TC: What options are on the table? Colon, arrow, equals?

Amanieu: Equals won't work now.

TC: I'd suggest arrow. Colon is blocked and requires lang discussion.

Josh: I don't think we should decide on what's blocked. We've been waiting for this long enough.

Josh: But I do prefer the thick arrow. Wouldn't object if people would prefer colon.

TC: Thick arrow looks like macro syntax. That's the character that's most available when writing these macros. Mostly what you see out there in the ecosystem. People would get it, it'll feel natural.

Amanieu: Preference towards colon: we use it in debug and in structs. But if we can't accept colon I'll be happy with an arrow.

Josh: Next step: file an issue asking for colon to be removing from an expr. Followed by an FCP and we need to commit to saying we'll never want colon in an expr.

TC: Looking at the lang backlog / design meetings and how involved this question would be and the analysis we'd require... this is going to be an involved question for lang.

Josh: Involved background research or to decide?

TC: Don't think we'll get to it in 10-15 minutes in triage. This will likely require a design meeting.

Amanieu: Not willing to go through that effort trying to push that. Arrow it is.

The 8472: Found some interesting syntactic use for `HashMap::from`: https://github.com/crisidev/bacon-ls/blob/9e018c981bc2bd45f8ef540f537e464174530890/src/lsp.rs#L455-L461

The 8472: This formats nicely, not sure this would work similarly well with anything unbalanced.

Amanieu: Harder to see what's the key and what's the value.

The 8472: On multiple lines they're indented differently.

TC: You want the key on the 0 indentation and the value at the 4 indentation (if you need to break the line). That's what we'd do on the Style team. In that context, the indentation feels more natural with the arrow. We already do that for `match`.

The 8472: For big expressions we'd use block like we do in the match?

TC: That's an option. But you could indent it even without a block.

Amanieu: Anything else we need to resolve here?

Amanieu: A lot of people (here and in the previous RFC) mentioned they prefer colon over arrow.

TC: Why equals doesn't work here?

Josh: `a = b` is an expression. You can't have equals after than an expression.

TC: We could do the same thing as the serde.

Josh: At that point you'd either have to write a `tt` muncher or a built-in macro.

TC: We're the standard library.

Josh: Trivial to implement the colon version as a built-in macro.

Amanieu: Or a tt muncher.

Josh: Yes, but trying to avoid doing that.

TC: This macro is evocative of a language design construct. We'd still need to check with lang. But it simplifies things significantly if we could not go the lang route for the syntax.

TC: Procedurally, the simplist option is accept this ACP with a fat arrow and explicitly flag the syntax as an unresolved question.

David: The other unresolved question is what we'll do with the random state. Are we going to default to the default random state?

Amanieu: We should do the default thing or the type inference will complicate things.

David: The `quote::quote_span` macro does this. It's possible to do this but it requires some trickery.

TC: We shouldn't constraint this if we have options.

The 8472: Should we shorten the name (for when we're building nested structures)? `map`, `hmap`, `hashmap`.

Josh: I wouldn't remove the underscore -- goes against our typical style. `hmap` is not a bad idea -- we could add `bmap` later.

Amanieu: I'd rather just keep this as hash_map. Realistically `HashMap` is more common than `BTree`.

TC: We also have `HashSet`. But I'd like to keep it short -- like `vec!`.

Amanieu + The 8472: The underlying type for `vec!` is called `Vec` though.

Josh + TC: But it can easilly be used inline not just as a multiline thing.

TC: People may well switch to using the macro instead of `HashMap::new`.

The 8472: We could capitalise it.

Josh: That would be inconsistent with `vec` and everything.

TC: I like `hmap`. Short, clear, makes trivial usecase appealing.

Amanieu: `HashMap` are never used that much (compared to vec). And I'd actually use it to create empty `HashMap`s.

Josh: Whether or not we name it as such, I wouldn't be surprised if people renamed this to something shorter on macro import.

TC: Let's add all this to the issue. Naming, open questions re syntax, link dtolnay's macro wizardry.

The 8472: compared HashMap::from and BTreeMap::from on github code search. Roughly 5:1 ratio.

TC: I think one of the reason people don't use hashmap that much is Rust because it's not as convenient. This might actually push up the use of HashMap.

Josh: Proposal that we summarise that we're very receptive to having this. Some back-an-forth on the syntax, but prefer using colon.

Amanieu: My concern about the short name is that it should just match the type.

Josh + The 8472: There's a lot of good uses for a single-line invocation (function arguments, a one-element hash_map).

TC: Losing the underscore is important to me.

TC: Don't think we've settled on preferring using colon.

TC: I don't want to use colon if there's any possibility to add type ascription or shifting to using `=` on the lang side.

Josh: Preferences for the syntax?

Amanieu: `hash_map! { "a": "b" }`
The 8472: `hmap!{"a"=>"b"}`
TC: `hmap!{..}` (deferring the token choice to later discussion)

The 8472: In match blocks you have the arms and the right-hand side of the arm can either have a comma at the end or use a block (or rather you could ommit the comma). Would that make sense here?

TC: I think I always want the comma? I'd have to see it.

Josh: I always like the comma. In practice you'll likely want to put paranthesis there and that would still lean towards needing a comma.

TC: There may be reasons to have a block there. Interesting open question, we'd have to look at it.

### (stalled change proposal) rust.tf/libs449 *ACP: Chars::take\_str*

Josh: Why is this not just split? Why do they want this on `Chars` specifically?

Josh: They want to advance the iterator but the example is pointing at the wrong char?

Amanieu: Shall we just close it?

Josh: It had a response the same day and then no activity for half a year.

Amanieu: I'll close this.

### (stalled change proposal) rust.tf/libs350 *std::slice::from\_raw\_parts alternative that would accept a null pointer if len == 0 by returning an empty slice*

Josh: We discussed this around a year ago. Mara said she'd prefer from_raw_parts work when the pointer is null and asked whether anyone run the perf run.

https://github.com/rust-lang/libs-team/issues/350#issuecomment-2007367995

No one did.

Josh: We should try that: just make `from_raw_parts` do that and a performance check to make sure there's no impact.

The 8472: We'd be adding a branch to all the Rust code just to enable some C code.

The 8472: The alternative that was mentioned was having `ffi::from_raw_parts` or something like that.

The 8472: Concern that very perf sensitive code would handroll this to get a branch-free version.

Amanieu: scottmcm's proposal for `NonNull::slice_from_raw_parts(p, n).as_ref()` does just that.

https://github.com/rust-lang/libs-team/issues/350#issuecomment-2091955205

Josh: And that was done a lot of releases ago. In the meantime having this more robust would be worth it.

Josh: Everyone okay with me writing up the summary above (please send a PR to try the experiment and do a perf run)?

The 8472: We could do this in two parts. First do this without updating the guarantee. And if no-one complains we can update the guarantee as a second step (and if they do complain, revert).

### (stalled change proposal) rust.tf/libs333 *\`NonNull::{from\_ref, from\_mut}\`*

Amanieu: Inclined to accept this.

Josh: Seems perfectly reasonable for me.

Amanieu: Counterpoint: we have ??

David: Didn't we stabilize this already?

Amanieu: We stabilised NonNull AsRef

David: We did stabilize this.

Josh: I'll summarize that.

### (stalled change proposal) rust.tf/libs365 *ACP: \`TwoSidedRange\` trait*

Amanieu: Inclined to close.

Amanieu: This provides subset of range bounds that only provides ranges with well-defined bounds. Where neither end is unbounded. Only implemented for `Range` and `RangeInclusive`.

Amanieu: The issue I have is this isn't used in the standard library at all.

Josh: Effectively this is a marker trait for third parties to accept a subset of our range types

David: But if this existed, we would have used it. For split_off.

Amanieu: For split_off is for only half-open ranges. This is only for fully-bounded ranges.

Motivating example: rand

Josh: I'd think ..6 would be enough here.

Amanieu: But not in floats.

Josh: This seems kind of reasonable.

Amanieu: I think this is very specific for how different crates want to use it. They should write their own traits.

The 8472: "Does this have to be in std" is one of our tests. If they don't have a motivation for why this should be in std we can close it?

Josh: Interesting that this binds into things that have an exclusing start bound.

Amanieu: This is closer to `Step` than range bounds.

Josh: The fact that it can return width is handy.

Amanieu: How do you define with when returning a float? Number of steps.

The 8472: The impls are bounded on `Step`.

Amanieu: `Step` is unstable, right.

Amanieu: I'm still inclined to close. The way these bounds are interpreted..

The 8472: Has anyone in the thread said why it would be good to have this in `std`?

Josh: Presumably the assumption is that this can be done in one way and it's useful to the ecosystem.

The 8472: It doesn't do float. The implementations for both Range and RangeInclusive has a step bound and we don't do that for float.

Josh: Should the `width` function also have a `T: Step` bound?

Josh: Amanieu: is your argument that this should be in the ecosystem not standard library?

Amanieu: Yes because everyone will want to do this differently.

Josh: Looking at the implementation it doesn't seem to have differntent behaviour.

Amanieu: It's really helpful when you want a range of `usize` but you want your API to accept `Range` and `RangeInclusive`. I think that's what it's trying to do?

Amanieu: Even the motivating example is worng. It sais it could accept `SampleRange` in `rand`. But `SampleRange` needs to support `float` which doesn't have `Step`.

Josh: Did you say tihs is superceded by 538? I don't think so.

Amanieu: I propose we discuss this in the Libs API meeting. I'll ask if 583 (proposed by the same author a year later) supercedes this one.

Josh: 538 is proposing something completely different. It does not supercede this.

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

Josh: Did we discuss this previously?

Amanieu: We did.

Amanieu: The ideal way to solve the problem is to reinvent the `fmt::Write` trait ??

Josh: This isn't as straightforward as it seemed. Let's try another one?

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

### (stalled change proposal) rust.tf/libs366 *Implementing UnixSocketExt traits for solaris/illumos ; starting with the unix\_socket\_exclbind feature*

Amanieu: We already have unbound socket, right? Yes.

Amanieu: Seems reasonable but I don't know much about this.

The 8472: It's just a socket flag.

Amanieu: Seems reasonable, I'm happy to accept this.

Josh: Seems like Solaris took a differen approach than linux on SO_REUSE_ADD/PORT. Interestingly, that seems to exist on Windows for TCP sockets.

Amanieu: Accept.

### (stalled change proposal) rust.tf/libs455 *slice::Windows::as\_slice*

The 8472: We have it in other places. Seems fine.

The 8472: They haven't given any examples for how it would work. I assume it'd return the remainder of what hasn't been iterated yet.

The 8472: I'll ask for clarification on whether this returns the remaining slice or the original slice.

### (stalled change proposal) rust.tf/libs202 *Support for non\-blocking and best\-effort zero\-copy \`io::copy\`*

Josh: io::copy already tries to do the efficient thing in the OS, but it doesn't do splice or sendfile.

The 8472: It does splice / sendfile in a few cases where it's safe. This relaxes

Amanieu: Is this an async copy?

The 8472: Not exactly. If you modify the source, it's unspecified whether you get the new or old value.

Amanieu: When the function returns, it doesn't guarantee that everything was copied already.

The 8472: Depends on what's being copied.

Amanieu: Does it misbehave today or just with the proposed changes?

The 8472: It used to, I fixed it for io::copy.

Josh: They propose three different possible ways to do this. Another option: make this work for file descriptors but not buffers.

The 8472: I think the idea for the buffer was to also support non-blocking io. If you return "would block" on the sender side, what would you do with the data you've already read as a reader. Sendfile would work. But if they don't support sendfile ??

The 8472: This is a low-level thing that supports sync and async copy.

*we didn't get to a conclusion and ran out of time*

### (stalled change proposal) rust.tf/libs335 *ACP: \`PathBuf::has\_dir\_suffix\`*

Josh: Seems reasonable. Effectively: ensure trailing slash.

Josh: Name seems confusing. Didn't occur to me that "dir suffix" could be talking about the slash/separator. "has_trailing_sep" / "with_trailing_sep" feels better?

Amanieu: FWIW I understood what it was about immediately. Don't care too much, be happy with both.

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