Allow serialising format_args! directly

[clarfonthey]

I've seen a fair number of Serialize implementations that involve calling to_string and I wonder if this extra allocation could be removed somehow. Take this example from chrono:

serializer.serialize_str(&format!("{:?}", self))

I wonder if we could perhaps modify this to:

serializer.serialize_str_format(format_args!("{:?}", self))

So that the serializer could call write itself directly to a buffer. For formats that don't require escaping characters, this could involve writing the data directly to the output stream, and for formats that do, this might involve writing to a temporary buffer (only allocated once) and then copying the data out with the escaped characters in it. Perhaps it could also default to calling format and then serialize_str if implementors choose to not specialise it.

Not sure how much of a performance gain this would be, but it seems worth investigating imo.

[clarfonthey]

Possible specialisations for ease of use could be:

• serialize_str_debug(val) -> serialize_str_format(format_args!("{:?}", val))
• serialize_str_display(val) -> serialize_str_format(format_args!("{}", val))

[dtolnay]

Neat idea. The chrono impls could be optimized similar to this and I doubt there would be much performance left to gain after that, but it may make a difference in other cases. This ties in to #746 as well.

[dtolnay]

@nox would something like Serializer::collect_str<T: Display>(self, T) with a default impl do the trick?

[clarfonthey]

Personally, I'd rather not limit this to just types with a Display impl because that requires a lot more boilerplate.

[nox]

@clarcharr This is the only way I can think of of using the Display trait while not making a breaking change. What do you suggest?

[dtolnay]

Can you give an example of the boilerplate it would require? FormatArgs has a Display impl so serializer.collect_str(format_args!("{:?}", val)) would use the Debug impl of val.

[nox]

Or do you just mean to support Debug too?

[nox]

@dtolnay Actually it should probably be Serializer::collect_str<T: Display>(self, &T), no?

[clarfonthey]

Oh wait, I wasn't aware that FormatArgs implemented Display. That works.

[clarfonthey]

The type of boilerplate I was thinking of was that using wrapper types to manually implement Display could feel a lot like boilerplate, but if FormatArgs allows that then I think that it's fine to only require that for complex implementations.

[dtolnay]

Instead of basing this on Display, it may be a good opportunity to base it on a trait of our own that is able to provide both a human-readable string representation and a compact binary representation. This would make a lot of sense for chrono, IpAddr etc. The idea would be that JSON and YAML and TOML serialize as a string while Bincode serializes as bytes.

[clarfonthey]

I mean, I think that there's value in having a minimal display trait for strings as well. Because the value sent to Display is usually intended to be human-readable, there are often more compact ways to display things.

One example off the top of my head is that an object containing dates might want to display them in a format other than ISO, whereas a serialised format would likely prefer ISO.

[nox]

That seems like a job for #[serde(with)], orthogonal to a method for the Display trait.

[dtolnay]

I filed #790 to follow up on the readable vs compact aspect of this in a separate change.

[dtolnay]

Fixed in #789.