Libs-API Meeting 2025-09-30

--- date: 2025-09-30 url: https://hackmd.io/LZdQ1_ZVS8aUrZm2KTtnYA --- # Libs-API Meeting 2025-09-30 ###### tags: `Libs Meetings` `Minutes` **Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr **Attendees**: Amanieu, Martin (martinomburajr), David, The 8472, Urgau, Lori, Tomas Sedovic, Josh, TC Notes: Tomas ## Agenda - Triage - Anything else? ## Triage ### FCPs 29 rust-lang/rust T-libs-api FCPs - merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left) - merge rust.tf/140808 *Implement Default for &Option* - (3 checkboxes left) - merge rust.tf/143191 *Stabilize \`rwlock\_downgrade\` library feature* - (3 checkboxes left) - merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left) - merge rust.tf/65816 *Tracking issue for \`vec\_into\_raw\_parts\`* - (3 checkboxes left) - merge rust.tf/146560 *Add the \`cpuid\` target feature* - (6 checkboxes left) - merge rust.tf/132968 *Tracking Issue for \`NonZero\<u\*\>::div\_ceil\`* - (3 checkboxes left) - merge rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16* - (2 checkboxes left) - merge rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* - (5 checkboxes left) - merge rust.tf/129333 *Tracking Issue for \`lazy\_get\`* - (3 checkboxes left) - merge rust.tf/136306 *Tracking Issue for NEON fp16 intrinsics* - (3 checkboxes left) - merge rust.tf/141994 *add Iterator::contains* - (3 checkboxes left) - merge rust.tf/63569 * Tracking issue for \`#!\[feature(maybe\_uninit\_slice)\]\`* - (3 checkboxes left) - merge rust.tf/145656 *Stabilize s390x \`vector\` target feature and \`is\_s390x\_feature\_detected!\` macro* - (4 checkboxes left) - close rust.tf/136638 *warn on empty precision* - (4 checkboxes left) - merge rust.tf/145628 *\[std\]\[BTree\] Fix behavior of \`::append\` to match documentation, \`::insert\`, and \`::extend\`* - (3 checkboxes left) - merge rust.tf/145610 *Stabilize \`char\_max\_len\`* - (3 checkboxes left) - merge rust.tf/145722 *implement Extend\<{Group, Literal, Punct, Ident}\> for TokenStream* - (3 checkboxes left) - merge rust.tf/145948 *Stabilize 29 RISC\-V target features (\`riscv\_ratified\_v2\`)* - (4 checkboxes left) - merge rust.tf/135889 *Tracking Issue for \`VecDeque::pop\_front\_if\` & \`VecDeque::pop\_back\_if\`* - (3 checkboxes left) - merge rust.tf/126769 *Tracking Issue for \`substr\_range\` and related methods* - (4 checkboxes left) - merge rust.tf/144090 *Make \`IoSlice\` and \`IoSliceMut\` methods unstably const* - (4 checkboxes left) - merge rust.tf/146561 *Change \`Location\<'\_\>\` lifetime to \`'static\` in \`Panic\[Hook\]Info\`* - (4 checkboxes left) - merge rust.tf/146705 *Tracking Issue for \`fmt\_from\_fn\`* - (3 checkboxes left) - merge rust.tf/146882 *fully deprecate the legacy integral modules* - (3 checkboxes left) - merge rust.tf/145665 *Don't require \`T: RefUnwindSafe\` for \`vec::IntoIter\<T\>: UnwindSafe\`* - (3 checkboxes left) - merge rust.tf/117729 *Tracking Issue for \`debug\_closure\_helpers\`* - (3 checkboxes left) - merge rust.tf/143812 *Tracking Issue for \`const\_slice\_rotate\`* - (3 checkboxes left) - merge rust.tf/146013 *Add \`From\` impls for wrapper types* - (3 checkboxes left) 1 rust-lang/stdarch T-libs-api FCPs - merge github.com/rust-lang/stdarch/issues/1908 *Make some remaining X86 intrinsics safe* - (3 checkboxes left) [dtolnay (2)](https://rfcbot.rs/fcp/dtolnay), [Amanieu (2)](https://rfcbot.rs/fcp/Amanieu), [joshtriplett (21)](https://rfcbot.rs/fcp/joshtriplett), [BurntSushi (21)](https://rfcbot.rs/fcp/BurntSushi), [traviscross (1)](https://rfcbot.rs/fcp/traviscross), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [scottmcm (4)](https://rfcbot.rs/fcp/scottmcm), [m-ou-se (27)](https://rfcbot.rs/fcp/m-ou-se), [the8472 (16)](https://rfcbot.rs/fcp/the8472), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis) ### (nominated) rust.tf/75027 `P-low` *Tracking Issue for slice::array\_windows* Amanieu: Similar to `as_chunks` it returns overlapping windows. Amanieu: The unresolved question is whether we want to do a compile/runtime check for the end. The 8472: Scott lists a suggestion that we could return an empty slice instead. This makes sense for windows but not chunks. Josh: That seems like a footgun. Can we do the same thing as we did for as_chunks? The 8472: Did we do a post-mono error or a runtime check? Josh: We did a runtime error. The 8472: That would be okay and we could do it later. Amanieu: `windows` panics when the size is zero. Josh: That makes it more sensible to use this. Amanieu: Can we do a `mut` iterator? The 8472: We could do it for a slice of `Cell` I guess. Amanieu: I'm inclined to stabilise this with runtime checks. The fact we don't have a well-defined behaviour for `windows` makes it weird to have a well-defined behaviour here. Amanieu: I'll start the FCP. TC: Is there a plausible well-defined behaviour? Amanieu: You get n zero-sized windows. But it's not useful. TC: We can always change our mind later, probably, by allowing what we're panicking on. Amanieu: Probably. TC: For posterity, the other option is to use the trick where we separate the const check from the call itself. You'd have the const constructor that checks that `N>0` and we return a witness type confirming the check has been done; then we hang the actual method on that. That avoids the language problem of not having `const if`. Amanieu: Seems excessive here. TC: Agreed. ### (nominated) rust.tf/142506 *Add \`Path::has\_trailing\_sep\` and related methods* Amanieu: We discussed this last time. Josh said we should keep the current behaviour and I was happy with that. Amanieu: I can reply with our conclusion from last week. ### (nominated) rust.tf/143191 *Stabilize \`rwlock\_downgrade\` library feature* Amanieu: This is waiting on checkboxes: Josh, BurntSushi and Mara. Amanieu: If everyone's okay with it, I'm going to check all her boxes. The 8472: Doesn't that automatically trigger a lot accepts? David: I think it'd be better if The 8472 would check these boxes. TC: On the lang side, in terms of process, when we have membership changes, we just cancel and restart the FCPs. Josh: If it's been around long enough that our membership has changed, it's not a problem to restart, check all the checkboxes that were checked in the past and continue from there. ### (nominated) rust.tf/145504 *Add some conversion trait impls* Amanieu: We discussed this last week: https://github.com/rust-lang/rust/pull/145504#issuecomment-3324599938 Amanieu: We should explicitly say that the rest seem okay to proceed. Josh: The follow-up said `alloc` fails to build when we provide the corresponding traits for arrays/slices of char. The 8472: The author replied that the `as_str` were created only because they exist so we can just drop them. ### (nominated) rust.tf/146099 *Stabilize \`debug\_closure\_helpers\`* Amanieu: That was for an FCP. I'll un-nominate it. ### (nominated) rust.tf/146660 *Tracking issue for release notes of #146410: Iterator repeat: no infinite loop for \`last\` and \`count\`* Amanieu: A lot of people said this behaviour is surprising. TC: I looked at this last week, including all the impls, and I thought this made sense. I think the arguments in favor of the change are sound. Amanieu: They are, but the original version did not go through an FCP. TC: Obviously, it should be Libs-API FCPed. Amanieu: We did do an FCP on the tracking issue. Josh: The fact that DoubleEnded iterator does exist and we've already done that for some other DoubleEnded iterators where people might find it confusing. TC: Amanieu, what you said on the issue was particularly persuasive, that due to our other decisions, these iterators are infinite in the middle with well-defined ends. The 8472: Also it's not a question of general policy. Repeat is just cloning the elements. If we did this on other iterators that have side-effects, that would be different. Amanieu: We have a DoubleEnded iterator of Take of Repeat. That's the only ponetially suspicious. Josh: Take is by definition finite so last is perfectly sensible on that one. The 8472: We explicitly implemented it that way. The 8472: `Repeat` also exhausts the iterator without cloning it. And I think we explicitly decided somewhere that `Clone` is now acceptable to skip. Amanieu: For a lot of DoubleEnded iterators we explicitly override `last` for optimization. `Repeat` is the only infinite one we have? Amanieu: Are we happy to stick to this? Do we want to roll this back? Josh: I think we should keep the behaviour of `last` for Repeat. And we should add documentation for things like `repeat_with` is not this way and that would be an infinite loop. TC: To build on Josh's point, I'd suggest in the documentation that we note the connection to `DoubleEndedIterator`, and that will help make clear why `RepeatWith` has different behavior. The 8472: An example where we don't optimize the behaviour but we could is the `Chain`. Where it exhausts the first iterator before trying the second iterator, it could go to the second iterator directly. Amanieu: If DoubleEnded iterator is implemented, is it always valid for `last` to call `next_back`? Josh: The alternative interpretation is: if `last` is interpreted as potentially going through the rest of the items, intentionally calling side-effects. At this point I'd be surprised if someone doesn't have a side-effectful DoubleEnded calling last and expecting for the side-effects to trigger. TC: I would find that a confusing expectation for `DoubleEndedIterator`. Josh: Map implements DoubleEndedIterator if the underlying iterator is double ended. And today, Map::last will iterate over all the items and that is an observable behavior. If we changed that to invoke `next_back`, that would be an observable side-effect that will probably break someone. TC: The way I would documented is I'd say that `last` is intended to call `next_back` and here are a list of places where we haven't done that (yet, maybe) for backwards compatibility reason. Josh: I'd argue instead that we should instead say "on iterators where " Amanieu: Today the documentation explicitly says that the method will evaluate the iterator until it returns `None`. Josh: And that is observable to people. TC: I'm thinking about people in the ecosystem who are implementing this. They'll be looking at the documentation on the trait methods for what a valid implementation is. It'd seem bad to tell people writing new code that calling `next_back` for `last` is wrong. Amanieu: You can have last call next_back only if advancing the iterator has no side-effect. The 8472: With the asterisk that Clone and Drop and Deref are considered to have no side-effects. Amanieu: Those are considered side-effects. For Clone we don't implement last. The 8472: That's what Repeat does now. We don't do all the clones. Amanieu: Repeat does have a side effect in that we have `advance_by` and `last`. Which calls `clone` no longer be called. And `drop` implications. Josh: Do we want to: (1) rever this, (2) ship the current behaviour when we're happy there's no side-effect or (3) optimizing of any DoubleEndedIterator and change the behavior here. Josh: I'd suggest we defer (3) here as that's a longer semantic argument. And we should look at keeping/rever this change? Amanieu: I'm somewhat inclined to revert. Josh: The release notes issue we're talking about is tagged 1.92. Amanieu: So we have until October 24 before the beta is branched. The 8472: I thisk this is fine the keep. Why would you use a Repeat iterator for an infinite number of Clones. TC: For arrays of elements that implement `Copy` we skip clone calls when you call clone on the array. And we do that even if the `impl of Copy` for the type inside the array has lifetime bounds that are not satisfied. It's because the library uses specialization for the implementation of `Clone` for the arrays. Amanieu: That's unsound. TC: Yes; there's an issue about it. The 8472: No one has managed to produced unsoundness without unsafe. Because there are no methods on Copy. TC: I agree with your analysis on the issue, The 8472, that this is unsound. Specifically the issue is that borrow check doesn't fire. Rust ignores lifetime bounds when selecting traits. But if you do this with some other way, e.g. with auto-deref-based specialization, the lifetime bound then causes an error to be thrown. The 8472: Can you exploit that? People tried and the only one that exists requires a deliberate copy on static implementation and that only compiles if you don't use it. TC: There's the "weird Cow" that theemathas posted. The reason this is hard to exploit is because the correct expectation is for this to produce an error. Since the expectation is to error, you can't have an expectation for it to do another thing. And I'm curious why it doesn't error. Amanieu: I believe specialization happens in codegen which is after the borrow checker runs. After monomorphization specifically. TC: Ah, right, that's the deep problem. It's happening too later to register the requirement. Amanieu: Back to this issue: should we revert? Accept? The 8472: I'd be in favour of accepting it as is. For this particular iterator I don't see any benefit of doing it any differently. Amanieu: It boils into the question: is the infinite loop a side-effect? The 8472: From libs-api perspective: are you going to write an infinite loop with an iterator with clone? Amanieu: The question is, should this be a panic instead? The 8472: That might compose poorly if an outer iterator calls `last` on an inner iterator. Amanieu: If it calls `last` on that inner iterator, it would never return. The 8472: You get less desirable behaviour instead of just making this work. Amanieu: The argument is that `last` on an infinite iterator is not supposed to work. The 8472: What's the benefit of that? Amanieu: `clone` and `drop` is an observable behaviour? TC: We could propose a new method for this. Amanieu: I'm still inclined to revert the change. It's not following the documentation. Josh: If you were to rever it, would you change it to an infinite loop or panic? Amanieu: I would change it to the infinit loop which is the correct behaviour. TC: I find myself agreeing with Amanieu. If we're saying the prescribed behavior of `last` is evaluating all the elements, even if the `Iterator` is `DoubleEnded`, and we're sticking to that, I think there's no other option than doing the infinite loop. I mourn that `last` is different than `next_back`, but if that's dead, then it's hard to see why `Repeat` should be different. The 8472: I still think that `clone` is not a significant side-effect and we should be free to remove it. We discussed this here https://github.com/rust-lang/rust/issues/140207#issuecomment-2842996190 Amanieu: Propose to revert? The 8472: I wouldn't tick my box on that one. Josh: The original change needed an FCP and we failed to produce one. We started doing one on the release notes issue. When people started to revert TC: This hasn't finished an FCP. If Amanieu files a concern on the FCP, it should procedurally cause a revert to 1.92. Amanieu: If we're reverting, is that the same as closing the release notes issue? Josh: Don't we need to rever the change in the code? We close the release notes issue but separately we need to go revert an actual change in the code. And that needs an FCP. The 8472: Arguably we did FCP it after the effect. Josh: But not successfully. We've started an FCP but we've not passed it. TC: If Amanieu files a concern, this won't FCP. If it's not FCPd we should revert it. Josh: It should always be possible to change ones mind. That's why we have the FCP process and release checks and stabilization. Amanieu: I'm going to ask for revert on this one and file a concern. ### (nominated) rust.tf/146674 *Make \`Map::last\` skip closure calls until last element* Josh: I just posted a comment to this one showing that this is an observable side-effect and objecting to merging as is. ### (nominated) rust.tf/146939 *Tracking Issue (take 2) for \`more\_float\_constants\`* Amanieu: There's a bunch of bikeshedding around the exact name for these things. David: If the language supported constants that could have const generic parameters, would that deprecate these? The 8472: We don't have arbitrary precision for stuff at const time. Amanieu: There amy be precision issues. The 8472: One of the FCPs mentioned they wanted these constants without rounding errors. David: I'd like to see this in a const library. Amanieu: I think that would be a great crate to have but not in the standard library. Why do you want generic functions. David: I think it's hard to define which constants, which of these values, which of these fractions is worth including. The number of constants we could feasibly include is a limited finite set. The number of constants that a library could propose is much higher. David: See this article: https://chadnauseam.com/coding/random/calculator-app TC: Here's the paper from Hans Boehm: https://dl.acm.org/doi/pdf/10.1145/3385412.3386037 TC: Yes, read that. Say more about how this would supersede the need for the constants. David: Suppose someone needs a constat that's an exact representation of log_3(sqrt(5)). Is that what we'd do in the standard library? And you'd be able to implement in a library with abritrary precision to get an exact value in your code. TC: Right. Seems plausible. TC: We should write this on the issue somewhere to see if we can tempt someone to write this. The 8472: What about the basic non-composite constants like phi and gamma? David: I'm happy to have these built-in, but they won't give you arbitrary precision. Amanieu: I don't see us coming to a consensus here. The 8472: For gamma, yes. Regarding the others, having constant-time arbitrary precision library may be better. Amanieu: Regarding naming: the constant gamma conflicts with gamma the function. The 8472: They're not in the prelude so you can just not import them if you need something else, right? I don't think the name is too important as long as it's correctly documented. TC: In our implementation of these for `f128` we give the precise value for that many bits, right? Amanieu: We should if we don't. TC: What if we scope this down to phi and gamma? The 8472: There is a specific library feature so we could stabilize the primite without stabilizing the primitive. Amanieu: Phi seems noncontroversial. Gamma seems more controversial: people want to call it GAMMA, EGAMMA, EULER_GAMMA. C++ calls it `EGAMMA`. That's what we've based all our constants one. The 8472: TrevorGross cites a bunch of precedents and C++ stands out. TC: I tend to like short names like EGAMMA. If I could find a good reason, I'd call it egamma. But, lacking that strong precedent, I think `EULER_GAMMA` is more parsimonious with how we name these sort of things in Rust. Amanieu: Basically, only C++ calls it EGAMMA. TC: I recall our discussion around naming `hash_map`. Some people wanted to call it `hmap`, but we've settled it up on the clearer name, and we'll all be happy with that. Amanieu: It seems C++ calls it EGAMMA only because of a conflict with the `gamma` function. We have one as well, unstable. The 8472: But this on the module not the primitive. And the capitalization is different so it really doesn't matter. I'm fine with either. David: It's not necessarily clear in the downstream code where there may be a different context using the same name. The 8472: Can you reimport the `const` module as `f32` module? Then you may be able to write `f32::PI` TC: I propose `EULER_GAMMA` and `GOLDEN_RATIO` as clear, explicit names that have good precedent from other numerical libraries like NumPy. David: That's my preference as well. The 8472: Then let's do that. Sounds fine. David: Especially the capital Phi is used in a lot of different contexts. David: If we do end up adding other constants that are derived from these and we'd have to add things like FRAC_1_SQRT_GOLDEN_RATIO, how would we name these. TC: I think I'm persuaded by your argument that we could lean on consteval for derived values. David: And you can also write a proc macro that does this. The 8472: If you do this on the proc-macro side, there's going to be compile-time overhead of building the proc macro. David: The compiler-time overhead is probably less than everyone doing build-std having to build the extra constants and downloading the documentation. The 8472: If we're only going to stabilise the basic constants, we don't have to discuss their names now, do we? TC: Are we good with `EULER_GAMMA` and `GOLDEN_RATIO`? Everyone: yes. TC: I'll write the summary. David: TC, for the other ones I don't object accepting them in the future. I object them without someone trying to do them in a library with arbitrary precision and for some reason that doesn't work. TC: Makes sense. ### (waiting on team) rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* ### (waiting on team) rust.tf/145608 *Prevent downstream \`impl DerefMut for Pin\<LocalType\>\`* ### (waiting on team) rust.tf/145722 *implement Extend\<{Group, Literal, Punct, Ident}\> for TokenStream* In FCP ### (waiting on team) rust.tf/146009 *Implement \`Receiver\` for \`Exclusive\`* ### (new change proposal) rust.tf/libs663 *\`Box::take\` for taking the value out of a box without deallocating it* The 8472: That's splitting Box into its payload and allocation. You could do this with `unsafe`. But this would be a safe API to provide that behaviour. This is a mirror for `Box::write`. That seems reasonable to me. David: I agree. ### (new change proposal) rust.tf/libs662 *ACP: Add unchecked arithmetic methods for integer simd* David: Does SIMD has the same overwlow that integer does in debug mode? The 8472: I don't know. It also depends on which SIMD. The intrinsics, portable SIMD? But I assume getting the overflow flags would be more expensive to just wrapping. David: Who has context on portable SIMD these days? The 8472: @programmerjake seems to be active on portable SIMD and he commented here. > other than div/rem, the existing `Simd<T, N>` operations are generally equivalent to int::wrapping_op so are already about as efficient as you can get David: My inclination is to ping https://github.com/calebzulawski and ask them whether they want this. I can do that. ### (new change proposal) rust.tf/libs661 *ACP: More float constants* The 8472: That's the float issue. David I think you said we want to wait until someone tries this in a library? David: Yes. Reply later once the float tracking issue has been updaterd. ### (new change proposal) *ACP: std::rc::RcUninit for deferred initialization and await\-safe cyclic construction* David: I'm onboard with the idea but I'd need to see significantly better documentation. Looking at the API docs it's not clear why you would want this type. The 8472: A usage example would help. I'm trying to figure out how this fits together with `UniqueRc`. David: `UniqueRc` has already been inittialized with a value. Here you have `MaybeUninit`. The 8472: Is this not `UniqueRc<MaybeUninit<T>>`? David: `MaybeUninit` is mentioned in the ACP. That's a good question. The 8472: You'd probably need at least one `assume_init` which is unsafe at the end. David: Fair question. It's worth asking what this would look like using `UniqueRc<MaybeUninit<T>>`. The 8472: They mentioned field placeholders but not the main payload itself. I'll ask. ### (new change proposal) rust.tf/libs659 *Generalize ExactSizeIterator to QuantifiedIterator* The 8472: It seems to be impossible to implement this one in a backwards-compatible way. We're waiting for language features to make this possible (implementable trait aliases https://github.com/rust-lang/rfcs/pull/3437). The 8472: This would break users because if a user has as ExactSizeIterator, wraps it in a Map or something, and then pass it to a method expecting `ExactSizeIterator`, that would no longer compile. TC: We want to do something on the Lang side to allow evolving trait hierarchies. If the situation here is you can't touch this because it would result in breakage, that's the kind of thing we're looking to solve with that work. The 8472: Looks like we have a blocked label. I'll apply that here. ### (new change proposal) rust.tf/libs656 *implement Default for more iterators* ### (new change proposal) rust.tf/libs653 *ACP: Add 1 type parameter to \`RangeBounds\<Start, End = Start\>\` and all existing range types* ### (new change proposal) rust.tf/libs651 *ACP: Add API to write formatted data directly into a \`Vec\<u8\>\`* Tomas: There's a separate meeting between Amanieu and Josh that's been scheduled to work out a plan for merging `io::Write` and `fmt::Write`. That'll happen this week. ### (new change proposal) rust.tf/libs650 *Add direct access to the thread id* The 8472: We proposed an alternative with a TheradRef token but that had leak issues. Given that, we can probably say to add the ThreadId methods. I think I'm in favour now, but without the rest of the team here I don't want to move it on my own. TC: Josh said +1 on it two weeks ago. So you have a second. ### (new change proposal) rust.tf/libs647 *Add \`Waker::from\_fn\_ptr\`* The 8472: That's far outside of my area expertise. No opinion on it. We usually punt that to the async-wg. TC: I'll ping async-wg on it. ### (stalled change proposal) rust.tf/libs287 *ACP: Add \`FromByteStr\` trait with blanket impl \`FromStr\`* ### (stalled change proposal) rust.tf/libs459 *ACP: Expose rustc\_lexer::unescape Functionality in the proc\_macro Crate for Standardized Literal Parsing* ### (stalled change proposal) rust.tf/libs484 *Support \`vec!\[const { ... }; n\]\` syntax for creating a \`Vec\` of non\-\`Clone\` values* ### (stalled change proposal) rust.tf/libs347 *Context reactor hook* ### (stalled change proposal) rust.tf/libs295 *Create iterator function in std libs: split\_item\_mut()* ### (stalled change proposal) rust.tf/libs348 *std::os::unix::env::{argc, argv}* ### (stalled change proposal) rust.tf/libs354 *Add titlecase APIs to \`char\`* ### (stalled change proposal) rust.tf/libs195 *OS\-level \`thread::Builder\` priority and affinity extensions* The 8472: I think we need more people on this one. ### (stalled change proposal) rust.tf/libs194 *Fix:Introduce an interface to expose the current \`Command\` captured env var logic* ### (stalled change proposal) rust.tf/libs261 *add \`write\_fmt\` method to String, to make \`write!\` macro work without imports* _Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_