format-args/

[utterances-bot]

Behind the Scenes of Rust String Formatting: format_args!() - Mara's Blog

The fmt::Arguments type is one of my favorite types in the Rust standard library. It’s not particularly amazing, but it is a great building block that is indirectly used in nearly every Rust program. This type, together with the format_args!() macro, is the power behind print!(), format!(), log::info!() and many more text formatting macros, both from the standard library and community crates.
In this blog post, we learn how it works, how it is implemented today, and how that might change in the future.

https://blog.m-ou.se/format-args/

[NobodyXu]

For Pieces::String, I think it's a good idea to use a NonEmptyString instead of &'static str so that compiler can take advantages of that niche and reduce the size of enum, since the const string should never be empty.

[SpriteOvO]

This made me recall a pattern! macro that my co-contributor implemented for our logging library about a year ago. I've been planning to support more advanced flags (such as alignment and padding) in the future, by learning the implementation details from the standard library's format_args!, but don't know where to start. This post is definitely very helpful to me! 👍 Thanks!

[BartMassey]

This is really cool work. Thank you for doing it. I'm really curious to see how it all works out over time. As someone who does some embedded Rust, I'm excited that it might soon be reasonable for me to use core::format_args in my tiny programs. As someone who is concerned about the performance of Rust formatted IO (fasthello, rust-nonstdio), I'm excited that it might soon be more reasonable to use it in performance situations.

[kurtlawrence]

Great read and fantastic work!

[Swatinem]

Thanks a lot for the work and the great blog post.

I wonder if it would be possible to avoid using format_args! at all in more places.
In particular, I often find myself implementing custom formatting logic where all I want to do is to append a Display type to a string buffer.

Ideally, I would like to have something like fmt::Write::write_display (similar to fmt::Write::write_str) and String::push_display (similar to String::push_str).

Right now, I believe the only way to do this is via write! (or write_fmt(format_args!(…))), which I believe is just an expansion of the former.

I was surprised to read the code snippet you gave in the "Closures" section, as Display::fmt(&display_ty, Formatter::new(w))?; is pretty much what I was looking for.
I thought I was completely missing Formatter::new, but then I tried looking it up and found out that it does not actually exist ;-)

It would be really nice if one of these solutions existed though, as I believe in lots of cases, usage of format_args! could be completely eliminated.

[jabdoa2]

Great writeup and great work! Would it be possible to use your closure approach only in the release profile (or above a certain opt level)? Would that enable fast debug builds and fast runtime? Or is the compile time blow up too bad even for release builds?

[qrilka]

Typo in the pose:

...the compiles is able to efficiently optimize

I guess it should be s/compiles/compiler/

[miaomiao1992]

very nice article!