Unable to create Formatter

[71]

Issue

There is currently no (obvious) way to create a Formatter.

Example scenario

In my case, this is a problem because I'd like to display an element that requires informations from external data; I'd thus like to do something like this:

pub trait ContextDependantDisplay {
    fn display(&self, f: &mut Formatter, data: &Data) -> fmt::Result;

    fn to_string(&self, data: &Data) -> String {
        let mut formatter = Formatter::new();
        self.display(&mut f, data).expect("...");
        format!("{}", formatter)
    }
}

However, there is currently no way to create a Formatter, so I had to use a little hack instead:

fn to_string(&self, data: &Data) -> String {
    let fmt = {
        struct ManualDisplay<'a>(&'a ContextDependantDisplay, &'a Data);

        impl<'a> Display for ManualDisplay<'a> {
            fn fmt(&self, f: &mut Formatter) -> fmt::Result {
                self.0.display(f, self.1)
            }
        }

        ManualDisplay(self, data)
    };

    format!("{}", fmt)
}

I also noticed there is an existing issue about it, which requests the following thing:

Formatter should show where it's created, and talk about the details more.

Meta

rustc 1.24.0-nightly (5a2465e2b 2017-12-06)
binary: rustc
commit-hash: 5a2465e2b44ecdd3b5d835c0abe29e9a4c9dcfe4
commit-date: 2017-12-06
host: x86_64-unknown-linux-gnu
release: 1.24.0-nightly
LLVM version: 4.0

[bluss]

I don't think the solution is necessarily to create a formatter, but other ways of making the formatter available. In this case you are using format!() so its formatter can be made available, and then the formatted output is also placed directly into the resulting String, which saves copying. Like your workaround shows this can be achieved with a helper type, and we can make that a bit more general.

For example a more general helper like this can be used, it's a helper function and type called Fmt.

format!("{}", Fmt(|f| self.display(f, data)));

[tailhook]

I also would like to be able to create a formatter. Because I want to receive format string from user. I.e. at runtime receive a format string from +05, then construct formatter for that and format the value. Currently, to achieve that I must reimplement all the things: microformat parser (which is okay), Formatter itself and Display trait for all needed types. Which is too much.

Are there any obstacles for adding a constructor?

[MightyPork]

I just hit the same obstacle. I have a struct that can be rendered to string in different ways, and fmt.alternate() and friends just aren't sufficient to express this configuration. Having access to Formatter (or some more generic way to pass options in the {} formatting pattern) would let me avoid constructing throwaway strings

[kgv]

format is utility crate to make it easier to work with the Formatter.
It defines format wrappers (Debug, Display, Binary, ...) which implements respectively traits. For example LowerHex impl fmt::LowerHex, fmt::Display and fmt::Debug traits. Also it defines lazy_format helper macro.

lazy_format!(|f| self.display(f, data)).to_string();

[NeoGalaxy]

What is the philosophy behind hiding ways to build a formatter? Why do we need to use a utility crate or hacky ways when the standard library can for instance build a formatter from a buffer?

If we have a good reason, then yeah, let's maintain a utility crate. If we don't, then maybe we should consider exposing ways to build a formatter?

[dtolnay]

Closing now that there is a libs-team ACP for this: rust-lang/libs-team#280.