Tracking Issue for fmt::Arguments::as_str()

[m-ou-se]

Tracking issue for fmt::Arguments::as_str() (#74056), gated by #![feature(fmt_as_str)].

[nikki-nn4]

I don't quite understand fmt internals, but Make fmt::Arguments::as_str() return a 'static str. seems unnecessarily restrictive. And it breaks runtime-fmt which depends on hidden apis e.g. Arguments::new_v1

[tesuji]

Arguments cannot be generated at runtime because it cannot safely be done. So as_str returns &'static str makes sense.

[sfackler]

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: rust-lang/log#446

@rfcbot fcp merge

[rfcbot]

Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @KodrAus
• @dtolnay
• @m-ou-se
• @sfackler
• @withoutboats

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 this document for info about what commands tagged team members can give me.

[BurntSushi]

This SGTM. One question though. Are we sure that the 'static bound will always be correct here?

[m-ou-se]

fmt::Arguments 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 const too. But a non-static/constant format string will be a very different beast.

[BurntSushi]

That's what I figured, but wanted to make sure it was explicitly addressed.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[jhpratt]

Does this make any guarantees about when Some is returned? I've been interested in redoing the format_args! macro to be much more intelligent (and thus performant), but obviously don't know when it's possible to return something statically knowable.

[m-ou-se]

Currently it returns Some for format_args!("string literal") only. But my plan is to extend that also to format_args!("{}", "literal"), format_args!("{}", constant), and possibly also things like format_args!("a {} b {} c", const, format_args!("...")), etc. See #78356

[jhpratt]

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 Some to returning None. I don't suspect anything would be out-of-reach when reimplementing the macro, but you never know.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, 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.

[sfackler]

@jhpratt 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. format_args!("asdf")).

[Zoxc]

This function seems particularly bad for compressed formatting strings and breaks the otherwise clean abstraction.