Change:
Tracking issue for (), gated by .
I don't quite understand fmt internals, but Make fmt::Arguments::asstr() return a 'static str. seems unnecessarily restrictive. And it breaks which depends on hidden apis e.g. Arguments::newv1
cannot be generated at runtime because it cannot safely be done. So returns makes sense.
I'd like to be able to use this in the log crate to correctly implement a codegen optimization that doesn't really work otherwise: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
This SGTM. One question though. Are we sure that the bound will always be correct here?
is the result from parsing a formatting string at compile time. In the future, this might not always be a literal but might be a too. But a non-static/constant format string will be a very different beast.
That's what I figured, but wanted to make sure it was explicitly addressed.
:bell: This is now entering its final comment period, as per the . :bell:
Does this make any guarantees about when is returned? I've been interested in redoing the macro to be much more intelligent (and thus performant), but obviously don't know when it's possible to return something statically knowable.
Currently it returns Some for only. But my plan is to extend that also to , , and possibly also things like , etc. See
Yeah, I see that from looking at the source code. I was more inquiring about whether it would be considered breaking to go from returning to returning . I don't suspect anything would be out-of-reach when reimplementing the macro, but you never know.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I think you'd generally want to use it as an optimization only, but we can probably guarantee that it will return Some for certain cases in particular (e.g. ).
This function seems particularly bad for compressed formatting strings and breaks the otherwise clean abstraction.

Discussion:
/// # Examples /// /// ```rust <del> /// #![feature(fmt_as_str)] /// </del> /// use std::fmt::Arguments; /// /// fn write_str(_: &str) { /* ... */ }

/// ``` /// /// ```rust <del> /// #![feature(fmt_as_str)] /// </del> /// assert_eq!(format_args!("hello").as_str(), Some("hello")); /// assert_eq!(format_args!("").as_str(), Some("")); /// assert_eq!(format_args!("{}", 1).as_str(), None); /// ``` <del> #[unstable(feature = "fmt_as_str", issue = "74442")] </del> <ins> #[stable(feature = "fmt_as_str", since = "1.52.0")] </ins> #[inline] pub fn as_str(&self) -> Option<&'static str> { match (self.pieces, self.args) {

#![feature(exhaustive_patterns)] #![feature(extend_one)] #![feature(external_doc)] <del> #![feature(fmt_as_str)] </del> #![feature(fn_traits)] #![feature(format_args_nl)] #![feature(gen_future)]