As discussed elsewhere the void dependency has caused issues with no_std before. It is also (in my subjective opinion) just kind of gross, there should be no need to have crates for language features.

Fortunately there is a ! type now which does the same thing.

This crate features no benchmarks, yet claims to be "fast". Microbenchmarks may not be optimal, but it would be a start. They should also be set up to compare against core: after all, there's a race to win. :^)

I've found this crate quite nice, and I think it could be even nicer with macro support. Thanks to macros 1.1, it's possible to actually implement this now.

My current thoughts on design would be a fmt_merge!() macro analogous to core::fmt's format_args!(). It would produce a single value of some type which can be easily formatted. For the type, I would imagine sticking together a ton of Chains with another ChangeFormat<F, T> struct wrapping T which implements Fmt<Display> when T: Fmt<F>. Initially I would just think to support {}/{0} for Display, and add support for named arguments and other kinds of formatting later.

The other idea I've had for this would be to support deriving Fmt with a similar pattern. If the merging macro is implemented using syn and the proc-macro infrastructure, it could easily be reused to build something like the following:

#[derive(Fmt)]
#[fmt(
    // format for a specific formatting type
    "fast_fmt::Display",
    // exact same syntax as `fmt_merge!()`:
    "Hello, {}! It's a {} day.",
    self.world,
    if self.good { "good" } else { "bad" }
)]
struct DayDescription {
    world: &'static str,
    good: bool,
}

I don't necessarily have the time to build this now, but I wanted to throw some design ideas out there. If I were to work on this in the future, do you think it would be a good addition to the fast_fmt crate? If there isn't already an in-the-works macro implementation, that is.

The library is pretty nice without these, but they could make it even easier to use.

Thanks!