# Libs-API Meeting 2026-01-27
###### tags: `Libs Meetings` `Minutes`
**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, The 8472, Tomas Sedovic, David, Josh Triplett
## Agenda
- Triage
- Anything else?
## Triage
### FCPs
2 rust-lang/rfcs T-libs-api FCPs
- merge rust.tf/rfc3874 *build\-std: always* - (16 checkboxes left)
- merge rust.tf/rfc3892 *Complex numbers* - (6 checkboxes left)
17 rust-lang/rust T-libs-api FCPs
- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/149218 *Make PinCoerceUnsized require Deref* - (3 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/149978 *deprecate \`Eq::assert\_receiver\_is\_total\_eq\` and emit FCW on manual impls* - (3 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\`* - (3 checkboxes left)
- merge rust.tf/99301 *Tracking Issue for \`error\_generic\_member\_access\`* - (2 checkboxes left)
- close rust.tf/136638 *warn on empty precision* - (3 checkboxes left)
- merge rust.tf/98407 *Tracking Issue for \`Exclusive\`* - (0 checkboxes left)
- merge rust.tf/140808 *Implement Default for &Option* - (1 checkboxes left)
- merge rust.tf/141994 *add Iterator::contains* - (1 checkboxes left)
- merge rust.tf/76314 *Tracking Issue for atomic\_from\_mut* - (1 checkboxes left)
- merge rust.tf/125687 *Tracking Issue for \`new\_range\_api\` (part of RFC 3550)* - (3 checkboxes left)
- merge rust.tf/149926 *Do not deduplicate captured args while expanding \`format\_args!\`* - (5 checkboxes left)
- merge rust.tf/111688 *Tracking Issue for ExitCodeExt on Windows* - (4 checkboxes left)
- merge rust.tf/151576 *Stabilize \`core::hint::cold\_path\`* - (6 checkboxes left)
- merge rust.tf/148738 *Tracking Issue for minimal const \`ControlFlow\` methods (\`min\_const\_control\_flow\`)* - (4 checkboxes left)
[epage (1)](https://rfcbot.rs/fcp/epage), [BurntSushi (10)](https://rfcbot.rs/fcp/BurntSushi), [estebank (1)](https://rfcbot.rs/fcp/estebank), [matthewjasper (1)](https://rfcbot.rs/fcp/matthewjasper), [davidtwco (1)](https://rfcbot.rs/fcp/davidtwco), [Muscraft (1)](https://rfcbot.rs/fcp/Muscraft), [Amanieu (7)](https://rfcbot.rs/fcp/Amanieu), [scottmcm (5)](https://rfcbot.rs/fcp/scottmcm), [0xPoe (1)](https://rfcbot.rs/fcp/0xPoe), [nikomatsakis (6)](https://rfcbot.rs/fcp/nikomatsakis), [traviscross (1)](https://rfcbot.rs/fcp/traviscross), [joshtriplett (5)](https://rfcbot.rs/fcp/joshtriplett), [weihanglo (1)](https://rfcbot.rs/fcp/weihanglo), [jieyouxu (1)](https://rfcbot.rs/fcp/jieyouxu), [tmandry (2)](https://rfcbot.rs/fcp/tmandry), [cjgillot (1)](https://rfcbot.rs/fcp/cjgillot), [dtolnay (4)](https://rfcbot.rs/fcp/dtolnay), [Mark-Simulacrum (1)](https://rfcbot.rs/fcp/Mark-Simulacrum), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [oli-obk (1)](https://rfcbot.rs/fcp/oli-obk), [the8472 (12)](https://rfcbot.rs/fcp/the8472), [spastorino (1)](https://rfcbot.rs/fcp/spastorino)
### (nominated) rust.tf/99301 *Tracking Issue for \`error\_generic\_member\_access\`*
FCP finished. Should be merged?
Amanieu: Last week we said if we could get trait-to-trait downcasting, that would be better. But I believe that's not possible to implement efficiently.
Josh: We've not gotten a confirmation whether this is possible or a good way to do this. Even if this was opt-in, it seems ??. We could say this trait is tracked this way.
Amanieu: I think
David: Agreed with Amanieu. We should stabilize it as proposed in the existing FCP.
Amanieu: Do you mean ProvidableByVal / ProvidableByRef traits.
The 8472: If the downcasting does happen what are we going to do?
Amanieu: Deprecate but we'll have gotten use out of this for years.
Josh: And maybe we'll be able to implement these with that mechaanism.
Amanieu: Sure. Anyway, do we agree? We'd like to stabilize, currently blocked by ProvidableByVal / ProvidableByRef traits
Josh: The only thing that would change that if someone comes in saying they could get the trait-to-trait downcasting in the next few months.
David: Someone's looking at it, right?
Josh: I wasn't aware.
David: I'll send you the RFC.
David: The RFC: https://hackmd.io/@DiamondLovesYou/S1GkAqXx-l
The 8472: We can say we're going forward with this tentatively unless we get new information?
Josh: sounds good
Amanieu: Id'1 like to look at the RFC first
...
Amanieu: I looked at the RFC. It's very complex.
David: Is it complex in the implementation, the API or both?
Amanieu: Unclear. Not from skimming it and I haven't read it completely.
David: What the draft RFC demonstrates is what I think is a low-cost viable path that reasonably fits into Rust. Polishing the API and the implementation is a lot of work but at least I can't say that this is not viable now.
Josh: I appreaciate it's at least paying attention to cdylibs.
David: Context: the author is a Facebook employee and at Facebook we use dynamic linking for all (??) crate builds.
Josh: Would we want to do this for the Error trait or only for things like has_backtrace, has_exit_code and has_http_error?
David: ??
Amanieu: Everything that is a subtrait of error becomes immediately downcastable. I like the design.
The 8472: Should there be an attribute to opt-out?
Josh: A subtrait could opt out. Any concrete type implemnting an Error would not be able to opt out. If you implemented Error, you'd always have this metadata table. But it could be empty.
Josh: +1 on not waiting on this. It looks promising and if we shipped this, we'd get much cleaner provider API. But it looks complex, not ready in 6-12 motnhs likely.
David: ANd it's not looking at the multiprovider API.
The 8472: You could have an extra trait that would give you all of them
Amanieu: you could have a multicast macro
David: That doesn't help. For each of these traits you'd have to walk the chain of sources.
The 8472: The Provider impl isn't supposed to walk the chain of sources, each multi-request
would only query a single level.
David: Thanks for reminding me. Then what Amanieu says would work.
Amanieu: But you're still advocating on not going this route because you think this too far from being ready?
David: I'm saying that this is actively being worked on it. I'm not saying we should wait on it.
Josh: It's good to know someone's working on it.
Amanieu: So we're moving with the RFC as is?
### (nominated) rust.tf/149926 `P-lang-drag-1` *Do not deduplicate captured args while expanding \`format\_args!\`*
Josh: This was discovered when someone was looking at the language corner cases. We deduplicate the implicit format_args. If you reference the same thing multiple times, we only pass it on once. Shouldnt' be observable, but if that's a const item or something that has an effect. It's an optimization case, it's also confusing. Also would affect how we handle `println!("{x.y.z}")`.
Josh: Lang realized this is something we should discuss with Libs-API since it's a libs-api surface. Mara weighted on this saying that it should continue to be deduplicated because it's a performance optimization. The current discussion is: can we only do this optimization if it's unobservable because there's no interior mutability or similar?
The 8472: It's always been the behaviour. The `Deref` would be a new feature that no-one's relying on.
Josh: The question is: to what degree is this a behaviour people expect.
The 8472: Expecting multiple deref calls have more effects is weird.
Amanieu: If we move this to arbitrary expressions, there it should be clear that each is evaluated separately.
Josh: True. What we're doing here though doesn't look like expressions. So people might not see it that way.
Josh: But what we should do for the simple identifiers and `x.y` case. Dianne's proposal is to detect things that are simple local variables we're taknig reference to. And use that for the dedup optimization. I think that's good enough to solve the problem.
Amanieu: Sure
The 8472: If that's possible, that sounds good enough.
Josh: Referencing a global constant will also typically be pre-evaluated.
Amanieu: Can someone produce an interior mutability?
Josh: https://github.com/rust-lang/rust/issues/145739
Amanieu: Right. That instantiates a constant twice. If it's a local then you can't.
Josh: That's correct. You can't get this when you're referencing a local.
Amanieu: It has to be const with interior mutability.
The 8472: I'm still not sure it's worth to change this.
Josh: If it turns out we can't do the as-if optimization, I wonder whether it's still worth doing. But if we can, it's worthwhile.
Amanieu: So our preference is for: evaluate it multiple times, but only if the optimization's not possible.
Josh: That'd be my suggestion. But make it conditional on the optimization existing.
The 8472: There's already a concern filed on that.
David: Would you expect this conflicting with a dangling attribute?
Josh: Right, a drop with side-effects is another way to observe this. Possibly, if you have some object that's tagged that Drop doesn't do anything important, I'd expect we could treat that as the as-if optimization because it has not side-effect.
David: But that's not required in the initial optimizsation.
Josh: I think so. But you'd still have to mix this in with const. It'd be such a corner case that maybe even not worth optimizing at all.
Josh: Does anybody feel like they don't want to check their box or file an additional concern?
Amanieu: I'm happy to check my box regardless the optimization.
The 8472: I think it needs the optimization.
Josh: Please list that specifically, then. But I believe the optimization should be able to happen.
Josh: It would be great if we responded that we've talked about this as a team and mentioning our position.
Amanieu: I'll write it up.
### (nominated) rust.tf/150522 *Stabilize new inclusive range type and iterator type*
The 8472: We want to stabilize this in advance of the new edition so people can start switching over to it, right?
Josh: Yes. The only reason we'd be hesitant to stabilize is if the edition wouldn't move to it. But we've got sufficient information that we would do this so stabilizing this makes sense.
Josh: I'm also seeing a mention of excluding `is_empty`. People didn't have the context and I don't have that context.
Amanieu: An inclusive range can't be empty. ... actually it can if the end is before the start.
Josh: This is `RangeInclusiveIter`. It's calling `self.0.is_empty`. It's returning "is start after last". I'm trying to find the original FCP.
The 8472: I think we discussed `contains`?
Amanieu: I do seem to remember something about `is_empty`. (checks notes) `is_empty` on RangeBounds is a problem, but here it's fine.
Josh: I see. That makes sense, I'll summarize this.
The 8472: There was some discussion on the ACP that's linked form the tracking issue about `is_empty` on `RangeBounds` but we don't have to worry about that now.
Amanieu: The other concern was field names are "start" and "last" vs. "start" and "end" like for `Range`. Should we call these "first" and "last"? But if you think of a range of floats, is it really "first" and "last"? I'm happy with the names.
The 8472: I'm looking at the `RangeBounds` thing
Amanieu: If both ends are exclusive, it's questionable whether the range is empty or not
The 8472: And that can't happen for the ones that are being stabilized. Ok, let's continue.
Amanieu: I'm happy with "start" and "last". Any objections?
The 8472: For the exclusive range, the last one isn't really the last element you get by iterating. "end of a range" seems better
The 8472: This is for the public fields in Range and RangeInclusive
Josh: Do we need them to be consistent between various ranges? We should maybe name them differently if it's the first value that isn't vs. the last value that is.
The 8472: Will it affect people writing macros if we write them differently?
Josh: I don't think so. If you want to be generic, you should use the range syntax.
Josh: I'd ship the currently proposed API.
The 8472: Ah, they already have different names. Ok.
The 8472: So we just have to tick our boxes?
Josh: Yes.
Amanieu: I'll reply that we like the proposed names.
### (nominated) rust.tf/151576 *Stabilize \`core::hint::cold\_path\`*
Amanieu: Stabilization request for the`cold_path` hint.
The 8472: So we'll have three mechanisms: code attribute likely/unlikely and this. Are we fine with that?
Amanieu: I am.
The 8472: We might get future attributes like branch weight.
Amanieu: Unlikely.
The 8472: Other languages use them.
Amanieu: Does anyone use them?
Josh: Occasionally. But I don't think that should block us here. This works nicely in a match arm. If we want to have another mechanism for branch weight, we can add that in the future; that doesn't mean we shouldn't have *this*.
***
Trevor posted this in the Zulip meeting channel: https://rust-lang.zulipchat.com/#narrow/channel/259402-t-libs.2Fmeetings/topic/Meeting.202026-01-27/near/570403087
(some discussion that was missed)
Amanieu: It's an attribute on function argument which is stable.
Amanieu: Trevor is suggesting just removing likely/unlikely entirely
The 8472: if you return you would..
Amanieu: You'd add an else if you're returning it
The 8472: If you have `likely(a) && b`, can that happen?
Amanieu: I'm not sure that works. But it could.
The 8472: So it could express things `cold_path` couldn't
Amanieu: It's currently implemented in terms of `cold_path`
Amanieu: It does rely on MIR-inlining to work correctly.
Amanieu: Given that, are we okay with removing `likely`/`unlikely`?
Josh: Yes, that seems fine.
The 8472: If it's implemented that way anyway, I'm okay with it.
Josh: I think it used to feed somethnig to LLVM more directly but not anymore.
The 8472: I see.
Josh: I can also imagine wanting it for usability reasons. Maybe having `likely` is easier. We should check with the Rust for Linux folks if they prefer `likely` to `cold_path` it's easy for them to implement it.
The 8472: What does the rustc no_unwind attribute do?
Amanieu: I think it helps with inlining.
The 8472: If users can write that, then.. maybe?
Amanieu: We always mark all intrinsics as `no_unwind` when they don't unwind. I don't think it's actually need it here.
The 8472: Let's ask and if it's not neeeded, remove it.
### (new change proposal) rust.tf/libs735 *ACP: Document how escape\_debug escapes characters.*
The 8472: Our general approach to debug is not stable. I'm not sure about debug escape in particular.
Amanieu: People are using the debug output to escape things for JSON
The 8472: *screams*
The 8472: This is not the right tool for the job.
Josh: It's worth clarifying something: we don't make any promises regarding the output of the debug trait. The `escape_debug` method is something that has a clear interface we should document.
The 8472: Why?
Josh: Better documentation on that function's API is reasonable. It does have a stable API.
The 8472: It says "will escape characters similar to the debug syntax". We have other escape methods
Josh: I do think all the `escape_*` methods should be fully documented.
The 8472: Why?
Josh: The `Debug` trait is an exception.
Amanieu: It's defined is to do what debug str does
Josh: It's similar
Amanieu: Should we make them the same?
Josh: Do we actually think there's any likelihood we'll change the behavior of escape_debug?
The 8472: Maybe for a special unicode character where we may decide ot escape it or something
Josh: I'm saying we should document it
The 8472: Then we should document the Debug trait
Josh: I think there's meaningful difference. `escape_default` is documented. `escape_debug` does something different from `escape_default` and since it's not documented, the reader or I don't know what the difference is. If we don't want that behavior to be documented, can we create another method that does this and document that?
Josh: Either document exactly what `escape_debug` does -- if only for our benefit. Or that we add some method that does the same thing, document *that* and then have `escape_debug` use that but say it may change in the future?
The 8472: Like our subject to change documentation?
Josh: We can talk aobut subject-to-change separately. But I think we should document what this does.
The 8472: Where does it come from? We don't document the debug traits generally. What makes this different?
Josh: People can observe what it does. We don't explicitly say that this is subject to change. If we want it to be subject-to-change we should write it down. But I'm saying there's value in documting that.
The 8472: But I don't know what e.g. debug printing a string does. I don't *need* to know.
Josh: I'd propose we respond saying we're not going to document/stabilize what the debug implementation does. I think we should document what all the escape functions do. I'm reading the definition of what the ACPs proposing as the documentation and that seems like it's the same behavior as `escape_default` and that seems unlikely.
...
Josh: I see, `escape_default` say ??. `escape_debug` says *non-printable* unicode characters will be escaped. That sounds useful. If we're not prepared to document/stabilize it, we should add a method that does (e.g. `escape_unprintable`).
The 8472: As long as nobody asks for it, I don't think we should create a new API just for the sake of it. And this person isn't asking for escaping non-printable characters.
Josh: I think they're asking for the current behavior of `escape_debug` and just asking whether they can have it there or in a different implementation.
The 8472: They say wanting to serialize something into JSON. And JSON doesn't require escaping nonprintable characters, just control characters.
Josh: It doesn't require them, but it makes them much more readable.
Josh: Two ways to resolve: (1) document `escape_debug` without a subject-to-change note. (2) document what it does, add a note that's subject to change and add `escape_unprintable` that will be stable.
Josh: That method is almost always what people want for escaping for the characters in the string.
The 8472: I don't thin we need the second method until someone says they need a fixed behavior for something.
Josh: That's what this person is asking for. That's what I'm asking for.
The 8472: Why didn't you or them not ask for an ACP before? Why do you need this exact shape without knowing a few seconds before what exactly it does?
Josh: That was years ago when I dug into this and realised this is what I want. Had to load that contex.
Josh: I want a behavior that's obviously reversible not just for the machine but also a person.
The 8472: We should define the method's purpose before we do this. So we don't end up in another situation if we ever change the `escape_debug`.
Josh: I think that's actually a useful situation.
The 8472: Some things are just forever unstable.
Josh: What change are you proposing? Closing this and leaving the method undocumented?
The 8472: If we document it, we could just make it unstable without making a precise promise over which characters get escaped and which ones don't. Until someone comes in with a precise request and a justified usecase.
Josh: So you're feeling is the current ACP is not justifying that method. Why? Because they don't need it or because they should use another crate?
The 8472: Do they try to roundtrip it? If yes, that's an argument, but the question is still: is it not enough to use a crate?
Josh: Personally, I'd happily accept an ACP for `unescaped` function that would unescape all these things.
The 8472: But the `escape8259` crate hanna-kruppe linked has both escape/unescape
Josh: Proposal for now, I do think we should document it. I'm fine for now to document this as a debug feature and unstable function. And we're open to an ACP that would provide a usecase for having a stable function in the future.
The 8472: That's what I was asking. If someone says this matches this perfectly, we'd discuss it there.
Josh: I'd happily take an ACP for a (single) `unescape` function. But we can have that conversation when we have that ACP.
Josh: I can write up a brief summary for this.
Amanieu: So the conclusion is: we close this one?
Josh: We ask for a PR documenting `escape_debug` with a subject-to-change note.
Josh: For a future discussion, we could document the total set of escapes we'd produce without specifying which specific characters we will escape when.
The 8472: That sounds good, but my concern would be when e.g. a unicode changes.
Josh: I can document that.
### (new change proposal) rust.tf/libs734 *Add next\_chunk\_back to DoubleEndedIterator*
Amanieu: next_chunk is still unstable. We can add this to that feature.
Josh: That sounds pretty reasonable.
The 8472: It's weird that if your iterator length is not multiple, your chunks are misaligned. IS that going to cause confusion?
Josh: I don't think so. This is already writable today (`.rev().next_chunk().reverse()`) that's convincing me that we should include this.
The 8472: If take chunks of 2 elements and you have an iterator of 3. Then you'll always get the lone element at the end. IF you consume stuff from the end, then you get the partial chunk in the middle.
The 8472: We'd want this to be efficient.
Amanieu: Accept it?
The 8472: Okay.
### (new change proposal) rust.tf/libs733 *allow specifying whether \`Instant\` should be suspend\-aware*
### (new change proposal) rust.tf/libs732 *ACP: \`impl TryFrom\<{OsString, &OsStr}\> for String\`*
Josh: My first reaction is: "we din't already have this?" We have the literal functions that implement this so it's surprising we don't have `TryFrom` already.
Josh: We have `OsStr::to_str` or `OsStr::to_string_lossy` and `OsString::to_string`. All return a `Result`. `TryFrom` makes perfect sense.
Amanieu: That seems fine.
Amanieu: Do we have `TryFrom` for `Vec<u8>` to `String`? ... We do!
Josh: We have `TryFrom<&OsStr>` to `&str`. We don't have one from `OsStr` to `String` or `OsString` to `String`. So having these is completely reasonable.
The 8472: Was that the one in the past where we talked about filling a matrix?
Josh: These don't feel like matrix filling. These seem like reasonable things to want.
The 8472: Right, that was PartialEq or something like that.
Amanieu: What is the error type for `TryFrom`? If you get `Utf8Error`, it gets the str back, not the OsStr back.
Josh: A dedicated error type would be fine
The 8472: Can we make it generic? `FromUtf8Error<..>`
Josh: `AsBytes` is a method that returns a `&[u8]`
Amanieu: Add additional methods to get the `OsStr` back?
Josh: If you're on `OsStr`, sure.
Amanieu: what about `From<Path>` to `String`
Josh: Sure. I think we have methods from `Path` to `String`, don't we?
The 8472: We have `TryFrom<Path>` but it returns an `Option`
Josh: I'd propose we have these, have them use `Utf8Error` and optionally have `FromUtf8Error` allow you to get `OsStr`. No need for it to be generic, just have a different concrete type.
Josh: Maybe we should just make `FromUtf8Error` generic.
```rust
// S for source
struct FromUtf8Error<S=Vec<u8>> {
...
}
```
Josh: The more I think about it, the more I think making it a separate concrete type. So we don't have inference issues.
The 8472: We could make the type an alias to the generic.
Josh: We can do that later. Create aliases for the generic instanciations of those types.
Amanieu: Where are we at?
The 8472: Accept, use a separate error type for now. We can unify it later if necessary.
The 8472: But if we need for each TryFrom impl a separate error type, maybe we shouldn't have so many of these?
Amanieu: Yes, I preferthe generci optino.
Josh: I prefer the generic option but I'd like to prevent the scenario where we create a bunch of inference failures.
Amanieu: That should be mostly fine. This one is unlikely to cause issues. It's mainly when you access associated constant or item on String.
Josh: Proposal: we think this could be done by making FromUtf8Error being generic. And then explicitly state to verify when adding this that this doens't create inference issues. If it does, we can always make this a separate type.
The 8472: And consider having a type alias to see if that makes any difference.
Josh: I can write that up.
The 8472: It's unfortunate that the existing method is called `into_bytes`.
### (new change proposal) rust.tf/libs731 *ACP: \`BinaryHeap::pop\_if()\`*
Amanieu: We have `peek_mut` already but `pop_if` is easier in some cases.
Josh: This makes perfect sense.
Amanieu: This version of `pop_if` would not allow mutations though.
Josh: That seems fine. Does `peek_mut` ..
Amanieu: It will put it back into the heap
Josh: I see. In that case `pop_if` should not modify
Amanieu: If you're doing complex stuff use `peek_mut`
Josh: Or make a copy or any number of things.
Amanieu: I'll reply
### (new change proposal) rust.tf/libs729 *Infalliable conversion from \`ExitStatus\` to \`ExitCode\`*
Amanieu: You run a subcommand that has an `ExitStatus` and you want to propagate that to your own `ExitCode`.
Josh: It would be nice if they proposed the exact signature. They're calling an exit code "status". They're calling for a method `code()` that returns an `ExitCode` and a method `success` that returns a bool.
The 8472: If a child was terminated by a signal, it just returns a failure
Josh: The proposal is the `.code()` will return `None` if exited by signal.
The 8472: The `.code()` method already exists. In the base implementation
Josh: What are they asking for?
The 8472: For a conversion from one code to the other. The solution sketch is just the fallback I guess and I guess an OS-specific impl.
Josh: I was confused because I saw `from_exit_status` ??
Josh: This has an `ExitCode::from_exit_status` which I'm all for. Should we have `ExitStatus::to_exit_code` too? Any objection to my responding to that?
The 8472: Any reason we don't do this via the `From` trait?
Josh: My main concern is: we have a very fuzzy line. Sometimes we leave out `From` impls if we feel like you shoundl'nt invoke it automatically and only explicitly. I wonder if the coversion is sufficiently lossy to make it a `From` impl. I'm okay with making it a `From` impl
The 8472: The question is: is this conversion is too oppinionated and someone might wish for a different conversion? I'm usually not designing a lot of exit codes a lot. But other people might care more?
Josh: I have programs that either return either success or failure and then programs that run subcommands return the same code as the subcommand and reserve a special code for the main program's failure. But there are programs that are much more specific with their codes.
Josh: Why don't we add `to_exit_code` and `from_exit_status` and we can decide on the `From` impl later.
### (new change proposal) rust.tf/libs728 *Adding fallible shrinking to vec using \`try\_shrink\_to\` and \`try\_shrink\_to\_fit\`*
Amanieu: That one seems fine to me.
Josh: Today if you call `shrink_to` on a `Vec`, that reallocates, but do we currently panic if it fails to shrink?
Amanieu: If it fails to shrink, handle alloc error out of memory.
Josh: If these functions (realloc) fail, the original block is untouched
Amanieu: Are there any plans to do anything other than to ignore the error?
Josh: What do you do when `try_reserve` fails? Handle the error gracefully and report the problem.
The 8472: If it's not able to do the in-place shrinking it'd be forced to do copying alloc. That might run out of memory and you could handle that to release memory and try again. E.g. if your `Vec` is inside a pool and the pool needs to move it outside to resize it and that relieves a memory pressure.
Amanieu: This can absolutely fail but in most cases it is really rare.
The 8472: It might be more prevalent on non-desktop constrained environments.
The 8472: I guess people could detect the failure of comparing the before and after capacity but that's unergonomic.
Amanieu: It's such an edge case that almost no one will be using it. I want to ask them for their use case is.
The 8472: It sounds like they're using the `global_oom_handling` feature?
Josh: I think the usecase is "I want to handle errors without panicking". Exit and wind things down gracefully.
Amanieu: I plan to reply asking whether making the shrink_to alternative making ignore errors, therefore making them ??
The 8472: ??
Josh: I'm concerned about the case where you have a massive gigabyte vector, you shrink it to a megabyte and you're wondering where the gigabyte went.
Amanieu: It'll fail later.
Josh: I'm not arguing against it. But I'm hesitant. If your allocator is so dire it can't handle shrinking, maybe it's your allocator problem. Can you have a failure on linux to have realloc that fails?
Amanieu: Yes
Josh: So e.g. you have a 256 byte object out of a 256-byte pool and you want to give it a new object so you can ??
The 8472: ANd the pools can be several megabytes in size. And if you're on embedded, that might just run out of memory.
Josh: Alright.
Amanieu: I still want to ask whether we should just ignore error for shrink_to
Josh: It's worth asking whether they expect to handle the error by handling it gracefully. It's worth asking if they'd be served by shrink_to never failing
Amanieu: Let's gather information and revisit next week.
### (new change proposal) rust.tf/libs717 *Add \`\[\_\]::shift\_{left,right}\`*
Josh: shift_left inserts on the right and pulls off of the left keeping the thing the same size. `shift_rigth` ??
The 8472: It works even if your slice is zero length because you just take out what you shifted in. No error case.
Josh: this says "panic for N > self.len()" but I think it's reasonable to ask whether there's reason to have that. Or could we have it never panic.
Amanieu: I think panic is the right behaviour here. You can easily check the length.
The 8472: But you cannot get the behaviour of what we discussed earlier by the length check. If we remove the panic and you shift in more than the size and part of the shift-in out, you can still get the panic. It's more general if we don't panic and let the user choose.
Josh: Thats' my thinking as well. I'd love the idea to not panic unless Scott comes back and explains why we don't want that.
Amanieu: I prefer the panic, the API is simpler.
The 8472: The API signature is the same.
Amanieu: The one with `Option` would be harder to use
The 8472: IT wouldn't return an option
Amanieu: What does it do without panic?
Josh: The behavior is always: take the current array, prepend the thing you handed it, slide the window all the way to the left and let the rest fall out.
Amanieu: I see. I'd veto that for code size complexity reasons. Thats an entire new code path needed to added.
Josh: Is your concern performance or having the code handling this present?
Amanieu: Performance. I'd just panic in this case.
Josh: I can think of usecases for both panicknig an not panicking. Obviously the 0 case is trivial. The case requiring nontrivial amount of code is you're shifting something that's larger than the current (non-zero) array. Actually, is this more code? Isn't shift right given an argument and the return value implemented by reversing the arguments?
Amanieu: you have an slice with 1 elemnt in it. You shift right
```rust
let slice = &mut [100];
let ret = slice.shift_right([1, 2, 3]);
assert_eq!(slice, [1]);
assert_eq!(ret, [2, 3, 100]);
[1, 2, 3].shift_left(slice)
```
Amanieu: It doesn't work because array is a runtime slice.
Josh: It's not runtime, you do know the size of it. It's proposed for const generics using N.
Josh: You're saying you'd have a runtime check.
Amanieu: you can't just swap the arguments. The arguments have different types.
Josh: I see.
The 8472: Maybe there's a clever way to keep it compact?
Josh: Respond with: we might an idea to make it panic-free. If this can be done with little to no runtime performance impact, we'd potentially be interested. If it adds runtime impact or add substancial code complexity, ignore and do the panic.
Amanieu: The complexity as noted in the ACP is extremely simple:
* ptr::read the returned values
* ptr::copy (overlapping!) the middle N places
* ptr::write the inserted values
(none of which can panic, so there's no droppage concerns)
The 8472: We can do `ptr::read` on pointer slices. In most cases it would still optimize. We could still try it I think. At least propose it.
Amanieu: I'm still inclined to panic.
Josh: I'm inclined to panic if it's nontrivial. But I'd still like to try if it can be done of a couple lines of code.
The 8472: I agree with Josh.
Amanieu: Ok.
Josh: If it can't be done, I'm okay with shipping the panicking version.
### (new change proposal) rust.tf/libs713 *ACP: Add float constants for min/max limits of consecutive integers that convert to unique floats*
The 8472: I don't like the name.
Amanieu: The entire thread is about naming.
The 8472: I propose `MAX_DENSE_INTEGER`
Amanieu: "we're in favor of this as a team, go firuge out a name and tell us when you have something."?
### (new change proposal) rust.tf/libs712 *Add an \`fN::mul\_add\` variant that might round twice*
Amanieu: mul_add will do a fused multiply add
The 8472: That's expensive on hardware that doesn't have that
Amanieu: That's only on really old hardware thankfully
The 8472: Does this do runtime compile detection?
Josh: mul_add_relaxed is effectively: I don't care if it rounds, make it fast on the hardware
The 8472: We wouldn't do runtime hardware feature detection for this
Josh: Someone pointed out:
> LLVM has both llvm.fma and llvm.fmuladd
Josh: What's the difference?
Amanieu: it's fused / unfused
Josh: So llvm.fmuladd is the relaxed version?
The 8472: algebraic_mul/add?
Amanieu: those are still unstable
The 8472: If they were stabe we could tell people to use those?
Amanieu: Yes
The 8472: Is that too relaxed for anyone?
Josh: That allows for things like "I did an algebraic_mul followed by algebraic_div so I can do nothing"
The 8472: Yes. It also allows the compiler to ignore the difference between 0 and -0
Josh: We don't have a ??
The 8472: our set of wrappers is kind of spotty.
The 8472: f32 has so many methods. What would be the meaning of algebraic_cos, etc.?
Josh: It has a meaning where you could say argebraic_cos followed by algebraic_tan (??) and notice you can't do anything
Amanieu: The concern: they can both have arbitrary large errors. They allow a lot more flexibility than the original proposal
https://github.com/rust-lang/libs-team/issues/712#issuecomment-3667610817
> how about when you're trying to make code run quickly on all platforms but still fit within specific error bounds? you can relatively easily compute those bounds for non-deterministically choosing fma or * and + since those both give specified answers, but algebraic_mul/add is basically asking LLVM to give you anything that vaguely resembles the input code and can have arbitrarily large errors.
The 8472: Is'nt it limited to a chain of algebraic operations. Won't it constrain the error bounds when more operations are added?
Amanieu: There's no constrain on the error bounds.
Amanieu: For algebraic_div of `1/x`, LLVM is only able to give you 8 bits of precision out of 53 bits
The 8472: Interesting.
Josh: I'm currently leaning towards adding `mul_relaxed`
Amanieu: Same
The 8472: Makes sense. I was under the assumption that LLVM is more constrained.
Josh: I think theres (1) I need perfectly deterministic every tyme (call mul_add), (2) I need precise error bounds (call mul_add_relaxed) and (3) I'm doing math and want the right answer and please go fast (call algebraic_)
Amanieu: Yes.
Josh: Conclusion, we'd like `mul_add_relaxed`. If you have even less concern for the error bounds and want to go as fast as possible, go use algebraic.
The 8472: Sounds okay
### (stalled change proposal) rust.tf/libs322 *\`AssertThreadSafe\` (name TBD) – a more general API for lifting conservative \`!Send\` or \`!Sync\` implementations*
### (stalled change proposal) rust.tf/libs296 *ACP: Designing an alternative \`FromStr\`*
### (stalled change proposal) rust.tf/libs192 *Report allocation errors through the panic handler*
### (stalled change proposal) rust.tf/libs111 *Restructure ptr\_metadata to minimal support*
### (stalled change proposal) rust.tf/libs552 *Provider\-style API for \`Context\`*
### (stalled change proposal) rust.tf/libs298 *Constructive/Destructive Interference Size Padding*
### (stalled change proposal) rust.tf/libs131 *Add \`std::fs::rename\_noreplace\`*
### (stalled change proposal) rust.tf/libs204 *Integer Manipulation API*
### (stalled change proposal) rust.tf/libs452 *ACP: Implement \`TryFromIterator\<T\>\` trait to compliment \`FromIterator\<T\>\` trait.*
### (stalled change proposal) rust.tf/libs191 *Add LocalWaker support*
_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_
Sign in with Wallet
Connect another wallet