Libs-API Meeting 2025-11-04

# Libs-API Meeting 2025-11-04 ###### tags: `Libs Meetings` `Minutes` **Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr **Attendees**: Amanieu, Chris Denton, The 8472, Connor, David, Tomas, Josh ## Agenda - Triage - Anything else? - Tomas: Project Goals open hours - Niko set up four meeting slots to [discuss anything project goals-related](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/2026.20plans/near/553456395) - Two are today (2025-11-04), the other two on Thursday 2025-11-06 - He's also sent an email to all@ with some proposal - If you have thoughts, feedback, anything to say about project goals, join one of the meetings: https://meet.jit.si/roll-over-beethoven ## Triage ### FCPs 12 rust-lang/rust T-libs-api FCPs - merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left) - merge rust.tf/146792 *Implement \`TryFrom\<char\>\` for \`usize\`.* - (3 checkboxes left) - merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left) - merge rust.tf/146560 *Add the \`cpuid\` target feature* - (5 checkboxes left) - merge rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16* - (1 checkboxes left) - merge rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* - (4 checkboxes left) - close rust.tf/136638 *warn on empty precision* - (3 checkboxes left) - merge rust.tf/98407 *Tracking Issue for \`Exclusive\`* - (1 checkboxes left) - merge rust.tf/145948 *Stabilize 29 RISC\-V target features (\`riscv\_ratified\_v2\`)* - (3 checkboxes left) - merge rust.tf/146660 *Tracking issue for release notes of #146410: Iterator repeat: no infinite loop for \`last\` and \`count\`* - (0 checkboxes left) - merge rust.tf/140808 *Implement Default for &Option* - (2 checkboxes left) - merge rust.tf/141994 *add Iterator::contains* - (2 checkboxes left) 1 rust-lang/stdarch T-libs-api FCPs - merge github.com/rust-lang/stdarch/issues/1935 *Make \`cpuid\` safe and update docs* - (4 checkboxes left) [Amanieu (4)](https://rfcbot.rs/fcp/Amanieu), [joshtriplett (2)](https://rfcbot.rs/fcp/joshtriplett), [scottmcm (4)](https://rfcbot.rs/fcp/scottmcm), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [BurntSushi (9)](https://rfcbot.rs/fcp/BurntSushi), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis), [traviscross (1)](https://rfcbot.rs/fcp/traviscross), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [the8472 (7)](https://rfcbot.rs/fcp/the8472) ### (nominated) rust.tf/135894 *Tracking Issue for \`atomic\_try\_update\`* Amanieu: The team's decision was to add `update` and `try_update` and deprecate the old `fetch_update` The 8472: It returns the previous value. Amanieu: Just in The 8472: I don't think these are an improvements. Here we just have `udpate` without context. It's clear enough in the documentation but just from the signature it isn't clear. Amanieu: The alternatiwe would be to return a struct with both the old and new value. The 8472: Or change the naming. Josh: Is `try_update` identical to `fetch_update`? Amanieu: It is, we're planning to deprecate `fetch_update`. The 8472: I think the old name is better because the ordering tells you it fetches first and then it updates. Josh: I feel `fetch_update` and `fetch_try_update` would hove been better. But then `fetch_update` should be `fetch_try_update`. The 8472: I think we should do what Java does and say `fetch_and_update` etc. Amanieu: I like just `update`. Josh: I'm fine shipping this, I don't particularly care. But if we're going to do this, we should update the documentation for `fetch_update` to say "this is `try_update`". The 8472: It would be great if we deprecate it in favour of something with better naming. Amanieu: Are we happy with these methods as proposed? Josh: Seems fine. Amanieu: I never use the update methods. Amanieu: Github code search for fetch_update returns around 4000. Are we happy with this much change? https://github.com/search?q=.fetch_update+Ordering+lang%3ARust&type=code&p=2 The 8472: If the name were better... Josh: The obnoxious part is that the name we want is the one that doesn't have "try" in it. Amanieu: Yes, which is why we're proposing just `update`. Amanieu: We'll start an FCP. Josh: Is there anything currently blocking atomic_from_mut (https://github.com/rust-lang/rust/issues/76314)? Amanieu: I've never needed it. Josh: It's been open for five years, it seems completely reasonable. It's an FCP away from stabilization. And people said that's something they want. Amanieu: If someone wants to start an FCP on it. I feel there's a bit of a lack of a usecase for this. The 8472: Apparently C++ has an equivalent. We're not inventing something new. Josh: Exactly. I'll start an FCP on this. Amanieu: I would like to see one person "I need this" before stabilizing. Josh: We have several people in the thread saying they want it. ### (nominated) rust.tf/145457 *Experiment: Add \`where T: Default\` to \`Default for \[T; 0\]\` impl.* David: We talked about this. There's a comment from lcnr where they said it would be easy to support without ; we said we'd like to ping lcnr. Amanieu: We did on Zulip. Josh: And I think lcnr said we shouldn't remove it. Amanieu: I'm still inclined to remove it. I think the motivation that we may need additional bounds in the future isn't enough. It's not breaking anyone today. Josh: It is breaking 9 crates in crater. It is churn. It works today. And we have a reason to think we will be able to support this in the future. I'd propoose we close this and specifically say we'd be happy to see the hack go in. David: I agree with Josh. And developing techniques for evolving the standard library is a good investment. Going the lcnr way will not only be to the benefit of the 9 current users. It will become part of our toolbox for the future evolution. The 8472: +1 Josh: I propose we link the zulip thread and close this issue saying that we expect we'll be able to implement this. The 8472: And we can see implementing it in the compiler and see how problematic that would be. Josh: Exactly, and seeing how much it would be in the compiler would let us compare the cost of the hack vs. cost of the breaking change. ### (nominated) rust.tf/148265 *library: core: document layout guarantee of \`TypeId\`* ... The 8472: *Concerns about generating a lot of TypeIds and balooning the binary size* Amanieu: TypeId is lazily generated only for types for which you generated `dyn Any`. The 8472: You can also call the `of` method of any type. Amanieu: In practice you won't get that many. Amanieu: TypeIds are often used with `dyn` and `dyn`s are often used with `Box`es and embedded often avoids allocations. So I'm not concerned about the size impact for embedded. Josh: It'd be good to get numbers. There can be a surprising number of types in Rust code. It'd be great to know how much of that is TypeIds. Are we talking kilobytes or megabytes? The 8472: It would only be in crates that do some type gymnastics. Not e.g. in rustc. Amanieu: I'd expet a complex program like ripgrep would have maybe 100 bytes of typeid. The 8472: I'm thinking of things like Bevy where they may be generating a lot of these. Amanieu: Even then I'd expect the overall size to be limited. You only get one of these per type. The 8472: One of the options that was brought up was storing the type name behind the pointer. Amanieu: Yes, that would be big. I wouldn't do that. The 8472: Maybe we can mention that but for the listed alternatives that might happen in the future should keep size constraints in mind. Tomas: I've missed the end of last meeting. Can you plesase give me a summary of what was discussed? The 8472: We mostly summarised the background and discussed whether we're okay with it. Whether it's lang, compiler or libs-api decision. We said we're going to defer to the compiler. If they say they want to make this guarantee, we're okay with it. But I came up with the concern about the size. The 8472: There are also concerns on the lang side: https://github.com/rust-lang/rust/issues/129030 ### (new change proposal) rust.tf/libs689 *Merge \`Vec::push\_mut\_within\_capacity\` and \`Vec::push\_within\_capacity\`* Amanieu: We added push-like methods that return a reference to the pushed element and we had to add separate methods for compatibility reasons. `push_within_capacity` is unstable yet. Are we happy for it to return mutable reference? Josh: I think it should clearly return a mutable reference. The 8472: We can't return an immutable reference because `Vec` stays borrowed. *this has been accepted* ### (new change proposal) rust.tf/libs688 *Initial state once cell value* Josh: The ask here is to provide a function that can fail and support trying again the next time someone ask and only caching the result if it's successful? Amanieu: `OnceCell` and `LazyCell` are two different things. `OnceCell` is basically an `Option` and `LazyCell` actually holds the function that initializes it. Josh: They're proposing a new Cell type. The underlying State type has Init/Uninit/Poison variants. The 8472: I think I've implemented something like that with Arc options. If the goal is to initialize something on demand and then try again later, then Arc swap works. You initialize it to `None`. Josh: Makes me wonder whether they want `StateLock` along with `StateCell`. Amanieu: Do they need a Cell at all? OnceCell is the equivelalent to Option.get_or_insert_with. What they want is a tri-state between uninit/init/poison. You start with uninit, try to initialize, if success you end up in init, if not you end up in poison. Josh: So they want to consume the uninit. If they didn't want to consume it, they could have just used a reference. Amanieu: Exactly. If the read from uninit is non-destructive, you just have a plain enum. Josh: I appreciate this is a case people might have but it seems too specialized for that particular case. I'd like to see something built ouf of smaller parts. The 8472: We talked about a dedicated poison type would that be helpful here? Amanieu: No, that's a different thing. Amanieu: Look at https://github.com/rust-lang/libs-team/issues/670, that seems to be the same thing Amanieu: LazyCell has this tri-state enum internally. This makes the uninit hold the arbutrary value rather than just holding `FnOnce`. Josh: That seems like a conflation. It's a tri-state but it knows that its initializer is a function and can be called. It's a single type serving two purposes not dependent on the type system but on the runtime. Josh: So the proposal is that `new` and the type would stop requiring function bounds but things like `force` or `force_mut` would keep requirining the function bound. And `get` because it doesn't call the function would not have the function bound. Amanieu: Yes. Josh: Ok, that's not horrible. Josh: Under what circumstances would you want to call `force_with` if you gave it a function. Ah, force_with takes `F`. Amanieu: The idea is that the function needs to access the borrow-state and you don't want the lifetime to the cell itself. Josh: Then 670 does sound reasonable. Josh: If you give it a function, it will be callable. Amanieu: You're usually better off using a mutable reference to some sort of tristate enum instead of using a Cell. Josh: Don't you in that scenario need something you can modify that's global? I.e. you still need a Cell? Amanieu: You redesign your API to take `&mut self` instead of `self`. Josh: The case I'm talking about is what do you do when you need a global. That's a common usecase for OnceCell. Amanieu: The examples don't show globals though. Josh: They show `App` but that same thing would alse be done with global. The 8472: Or an `Arc<App>` where you only have access to `borrow`. Amanieu: I still feel this is an antipattern. We should ask if it would be better to take the thing by mutable reference. And if so then Cell is the wrong approach. Maybe you can provide this tristate enum as helper type. Josh: In the examples given, where do you expect the state to live in? Amanieu: Some tristate enum that is uninit. The solution can be just theenum `State` without the `StateCell`. Josh: You're proposing they have a Client that has a value that's a type of enum that has three different values? Amanieu: Yes. Josh: It feels like they'd be reimplementing LazyCell. Amanieu: The acess model is different. This requires access by ?? Josh: So your expectation would be: "take an enum, leave it poisoned, take it to an initializer function". You're not proposing a mutable reference but a value you read and write. The value would directly live in self. Amanieu: Yes. Josh: That would work in any time they don't have a shared mutability. And if they would, what would they do? Amanieu: Then they would need the functionality proposed here. People should not be using Cell as the first resort. They should change the design of their API though. Josh: I expect more than 50% of LazyCell or LazyLock to be global. Amanieu: Sure but the examples here are not globals. The 8472: The difference between a global or a single Application object that's being passed everywhere. Josh: The difference is that you don't have to pass the reference everywhere in your program. Josh: It feels like we're currently relitigating teh existence of Cell and interior mutability. Amanieu: That's not the case. What I'm saying is: if this method on your type involves mutation, you should make it take `&mut self` not `self`. The 8472: You need some mechanism to go from a shared reference to getting a mutable reference. Amanieu: And your method on the outside should take `&mut self`. The 8472: No, the outside is the `&self`. Amanieu: I don't think we should expeose this functionality inside of the Cell without having it outside of the Cell too. Josh: That's a much more reasonable. Amanieu: The tristate outside of the Cell is the first thing that people should try. Josh: What it sounded like to me was you saying expose the tristate and not exposing it for Cell. Amanieu: Right, let's add both. Josh: If `State`'s going to be public, then we should have API on `State` to do more convenient initialization. They should be able to call `State::get_or_init` or something. Josh: Could this be a `State` of two values and if you want poisoning, the `Init` value could have `Poison<T>` instead of `T`? Amanieu: I suppose that could work. Josh: Then you could do an infallible initialization of value without `Poison<T>` but if you needed a fallible initializaiton, you'd use `Poison<T>`. Amanieu: Sure. But you'll need to be able to atomiaclly replace the initial state with `Poison`. Josh: Are you thinking of it panicking and leaving the poison unitialized? Amanieu: yeah. JOsh: I was thinking of calling `take` and leaving it unitialized. Amanieu: That's not panic-unwind safe. This needs the tri-state. Josh: So even in the "infallible" state we still need the poison because it won't be unwind-safe otherwise. The 8472: The initializing functions only take the initial state by reference. So we could put it back in the infallible case. Josh: Good point. If you take `FnOnce` by reference then you don't need it. If you take it by value then you have to support that. The 8472: Yeah. Josh: We could still make it `State<I, Poison<T>>` to separate the concerns. And then have a two-value enum and we could have an initialization functions taking a reference and there you don't need a poison. Amanieu: The Cell can't take the reference. It requires Poison. Josh: Then let's separate `State` from `Poison` so `State` is a two-value enum and `Poison` is a semantic thing. So for non-Cell usecases we can have a two-value `State` for usecases such as a non-mutable reference that's not Cell. We make one variant and the user of Cell has a type signature that requires Poison. LazyCell would internally use `State<I, Poison<T>>`. Amanieu: We're going to sketch that and reply to the author and see if that's good enough for them. Josh: I can help with that. Amaineu: The proposal was `StateCell` and the alternative is 670 which is extending `LazyCell`. Josh: I think 670 is better than 688 because we have one `LazyCell` instead of two. Josh: So (a) we want to see `State` as public type. (b) we'd like to separate out `Poison` so it's not required for every use of `State`. (c) we also want to use the apporach documented in 670 rather than the one documented in this issue. And ask them whether that would work for their usecase. Amanieu: Ask them to see if they can get away with using the one without `Cell` since in general that's better. Josh: Sure. ### (new change proposal) rust.tf/libs687 *ACP: \`Path::is\_empty\`* Chris: This was rejected in 2016 because you should be testing path.componets for length. But that's always the same as `OsString::is_empty`. So we should be able to have `Path::is_empty` without it being ambiguous. The 8472: Is this just empty string or something else? Chris: Just the empty string. The 8472: We had some issue with an empty string in the past, haven't we? Amanieu: Yes, it was whether '.' was an empty path too. The 8472: It was the read dir one: https://github.com/rust-lang/rust/issues/114149 Amanieu: also: https://github.com/rust-lang/rust/issues/125112 Amanieu: `create_idr_all("")` succeeds with no-op. `read_dir` with empty returs with error. Chris: It passes it into the OS. Amanieu: `Path::is_empty` seems simple enough? Josh: I wrote code that converted this to a string to test whether it's empty last week. So yes. The 8472: Sounds fine. ### (new change proposal) rust.tf/libs686 *ACP: Add \`clamp\_magnitude\` method to float and signed integer primitives* Amanieu: A clamp with a signed +/- for limit. The limits are inclusive. Josh: So this is literally just `clamp(-argument, argument)`? Amanieu: Yes. The 8472: What if someone passes a negative argument? Josh: Panics if limit is negative or NaN. The 8472: That's not what I understood the magnitude to be. Josh: You'd prefer dropping the assert and always take the absolute value? Amanieu: On integer types it takes an `unsigned` integer. Josh: If the clamped magnitude is bigger than the maximum signed value it just says "I'm done". That's great. The 8472: The behaviour is good but maybe we can optimize the branch away. Josh: I think you can reasonably argue for either behavior in the floating point version. Does `abs` panic on `NaN`. Amanieu: Nothing panics on `NaN` it just returns `NaN`. Josh: This panics on `NaN`. We should just specify the behaviour we want. If you pass in a limit of `NaN` you should return `Nan`. Amanieu: That's not the current implementation because of a behaviour of min vs minnm in IEEE floats. Josh: Clamp appears to panic on `NaN` Amanieu: Fair enough. Josh: If we call `clamp_magnitude(NaN)` we should be consistent. Amanieu: I prefer panicking on negatives. The 8472: I would have said not-panicking and let people filter out `NaN`s if they care. But that's not consistent with clamp. Josh: If `clamp` didn't panic on `NaN` I'd say return `Nan`, eliminate that panic and then eliminate all panics. But if we already have to panic on `NaN` then I'm all for panicking on negative as well. The 8472: Where do you get the `clamp` panic? ``` [src/main.rs:2:5] f32::NAN.clamp(-1.0, 1.0) = NaN ``` Amanieu: If the bounds are NaN it panics The 8472: I guess that makes sense, when you clamp you want to guarantee it being in some range. The assumption is that the left-hand side is untrusted data and the clamping is what's supposed to bring it in bounds? Hm, but the `NaN` still goes through. The arguments are trusted though. The 8472: I'm still not convinced that panicking on a negative value is sensible. Negative value has a well-defined behaviour: take a magnitude and clamp the magnitude. Amanieu: You already have a panic for the `NaN` check. Josh: That's what I was saying earlier. If we could eliminate the `NaN` panic, then we should eliminate all panics. Josh: That said, I wonder how breaking and whether it'd be desirable to make `clamp` not panic on `NaN`. The 8472: Not panicking on negative values could be useful for e.g. values coming in form cosine. Josh: both interpretations are completely valid and justifiable. The question is which one we want. I think we should be consistent with `clamp` in terms of panicking on `NaN`. Amanieu: If we force people to only put unsigned values then reading the code is easier. The 8472: Why would you need to panic on negative values? Tomas: There is a slight inconsistency between integers (which are only positive) and floats which could be positive or negative here. The 8472: But floats and ints are different values. Integers are not symmetric here. The 8472: Should we just ask the thread for people's opinions? Maybe people from the mentioned fields (audio, robotics physics) we could learn whether negative inputs would be unexpected or whatever. Amanieu: It's simpler to just panics. The runtime check has the same cost. We'd only do a single runtime check. If you're taking a negative input, call `abs()` on it. It will be optimised away. The 8472: But that adds more noise. Amanieu: If you add `abs` that makes it more readable. Josh: I agree, `abs` does seem like it makes it more readable. ### (new change proposal) rust.tf/libs685 *ACP: Add a \`partial\_sort\` method to \`\[T\]\`* Amanieu: We should cc sort expert who wrote the two sort implementations. Ask for their thoughts and defer to them. The 8472: There's a pretty straightforward implementation that Scott mentioned. To do `select_nth_unstable` + `sort_unstable` https://github.com/rust-lang/libs-team/issues/685#issuecomment-3471487610 Amanieu: `sort_unstable` doesn't take advantage of sorted data. Josh: I think our sort did. Amanieu: Only stable sort does that, not the unstable sort. Josh: The name is confusion. I thought it would be sort on `PartialOrd`. Amanieu: C++ calls it `partial_sort`. So does D. Everyone calls it partial sort. The 8472: Wikipedia describes this as partial sort. Amanieu: I'm happy to add this but I'd like the input from the authors of the sort algorithms. The 8472: Do we the stable or unstable? Amanieu: Both. `partial_sort` and `partial_sort_unstable`. *** Josh: What are the chances we might be able to ship some version of "sort floats"? Something that makes it able to sort a set of floats. Amanieu: Something like the ordered-float crate? Josh: Yes, but in the standard library. I'd like to stabilize https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.sort_floats-1 Amanieu: I've used an ordered-float and `sort_float` wouldn't help because I'm sorting tuples that have floats in them: https://github.com/Amanieu/regalloc3/blob/main/src/internal/allocator/order.rs#L88 Josh: I see, whereas `sort_floats` only works on arrays of floats (e.g. `[f32]`). Josh: Then can't we put ordered-float to the standard library? The 8472: Aren't there multiple ways to order floats? Amanieu: Total compare is the obvious one. The 8472: So everything that's not orderable compares as equal? Amanieu: I think the NaNs all go at the end. The 8472: That's different from what `total_cmp` does. Josh: Would the universe break if we put ordered-float but have it use `total_cmp`? Amanieu: It treats `0` and `-0` as equal. The 8472: Does it implement `Hash`? Josh: It does. I wonder if that's why ordered-float does equates `0` and `-0`. To be hashable. Amanieu: The advantage of ordered-float uses native float comparisons. Josh: I see so if you wanted to use `total_cmp`, it would be slower. Amanieu: Yes. Josh: That seems reasonable. It's unfortunate that it's different from `total_cmp`, but it's justifiable. Amanieu: Could we say that `sort_floats` is not the way and remove? Josh: I agree but could we also say that we'll bring ordered-float in as a replacement? The 8472: There are multiple ways to do the ordering. Josh: There are multiple ways to do total ordering too and we shipped one. Amanieu: IEEE defines the total ordering. Amanieu: I'm happy to add ordered-float to the standard library. Josh: I think we should add ordered-float. But ordered-float also has a NotNaN in it. But I'd add the entire OrderedFloat type pretty much exactly as written. The 8472: I'm sceptical this is the right approach. If other languages decide to ignore IEEE. Josh: Some languages do that, some languages start spewing NaN everywhere but they don't care. The 8472: What do you mean? Josh: Some languages don't make the distinction between floats and other types. They say you can of course sort them and just get `false` on a `NaN` comparison. Amanieu: I'm curious if C++ makes an undefined behaviour. The 8472: I think this would blow up sorts that confirm if you have an inconsistent predicate. Josh: I agree. I don't think we should make floats sortable. But we should let you do it if you want it. Amanieu: C++ just says undefined behaviour. Josh: In Python, sorting a float array with a NaN in it gives an undefined unsorted order. I don't think we should do that, we should add an ordered-float type. The 8472: We should document this is a bespoke ordering and there are other ways to order. ### (new change proposal) rust.tf/libs683 *Expose \`FloatErrorKind\` from private \`core::num::dec2flt\` to public \`core::num::FloatErrorKind\`* Amanieu: We responded last week asking for more details on the motivation. The 8472: We didn't get the answer from the author yet. ### (new change proposal) rust.tf/libs660 *ACP: std::rc::RcUninit for deferred initialization and await\-safe cyclic construction* Amanieu: We've accepted this. I'll set the label. ### (new change proposal) rust.tf/libs659 *Generalize ExactSizeIterator to QuantifiedIterator* Blocked, skipping. ### (new change proposal) rust.tf/libs656 *implement Default for more iterators* Waiting. ### (new change proposal) rust.tf/libs653 *ACP: Add 1 type parameter to \`RangeBounds\<Start, End = Start\>\` and all existing range types* Accepted. ### (stalled change proposal) rust.tf/libs191 *Add LocalWaker support* ### (stalled change proposal) rust.tf/libs186 *Implementing flatten for \`Option\<&Option\<T\>\>\` and \`Option\<&mut Option\<T\>\>\`* ### (stalled change proposal) rust.tf/libs336 *Add \`or\_try\_\*\` variants for HashMap and BTreeMap Entry APIs* ### (stalled change proposal) rust.tf/libs483 *\`Box::new\_from\_ref\` for making a \`Box\<T\>\` from a \`&T\` where \`T: CloneToUninit + ?Sized\` (and \`Rc\` and \`Arc\`)* ### (stalled change proposal) rust.tf/libs133 *Add fmt::Write to io::Write adapter* Josh: We had a long conversation on how we want `Write` to work. Does that impact this? Amanieu: I think in the end we decided that the new thing shoudln't automatically support the old traits. Josh: We have a trait proposal that is the replacement for the `fmt::Write` trait and a macro that uses it. Amanieu: We've basically wrote a new macro. Josh: The change was blocked on a change in the language that I've now made. Amanieu: We're introducing a new write macro which is based on the new trait and deprecating the old write macro and changing the error type. Amanieu: I don't see a need to convertfrom io::Write to fmt::Write. But I see a need to convert from the old trait to the new trait. Josh: That's what I was thinking too. Josh: We wouldn't need two wrappers, we'd need one. If you had the adapter from io::Write to the new one, then it can also support the fmt::Write. Amanieu: io::Write means "you can write bytes into this thing". The new fmt::Write means "you can write unicode into the thing". Josh: Both old and new fmt::Write let you write unicode into the thing. But the new one lets you not handling the errors when you're writing a string into a Vec or string. Josh: When we have this adaptor, when it implements to new fmt::Write str, the error type it returns can be io::Error. Josh: https://hackmd.io/xb-b_q4FQDKkwZEGQSaQwA ### (stalled change proposal) rust.tf/libs501 *ACP: Add floating point representation conversions* Josh: I responded to this a year ago saying I'm not sure we should provide an exploded enum type. Instead I proposed from_parts and to_parts and break it out into the three-element tuple. The 8472: How do you represent infinity in the tuple? Josh: Exactly how the bits represent it. Bart wrote this: https://github.com/BartMassey/float-parts/blob/main/src/lib.rs Josh: This seems like part of this. (we ran out of time, meeting ended here) ### (stalled change proposal) rust.tf/libs111 *Restructure ptr\_metadata to minimal support* ### (stalled change proposal) rust.tf/libs371 *ACP: primitive numeric traits* ### (stalled change proposal) rust.tf/libs261 *add \`write\_fmt\` method to String, to make \`write!\` macro work without imports* ### (stalled change proposal) rust.tf/libs462 *impl fmt::Write for BufWriter* _Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_