Add an easier way to append `T: Display` to `String` to stdlib?

libs
21

A collection of methods that are required to format a message into a stream.

This trait is the type which this modules requires when formatting information. This is similar to the standard library's io::Write trait, but it is only intended for use in libcore.

This trait should generally not be implemented by consumers of the standard library. The write! macro accepts an instance of io::Write, and the io::Write trait is favored over implementing this trait.

It seems the main reason fmt::Write exists at all is just because core::io stubbornly refuses to exist. Why doesn't it again? Aside from adding io to core, one possible solution to the Write ambiguity would be to have Error be an associated type to fmt::Result. For String, Error would be !, and io::Write could be aliased to fmt::Write<Error=io::Error>.

I would absolutely love to be able to use write!() without importing. Heck, would it possible for core::write!() itself to use core::fmt::Write; and std::write!() to use std::io::Write;?

If core::io was a thing, then fmt::Write could just be deleted entirely, or simply deprecated for backwards compatibility.

22

io::Write can't be implemented for String because it can be used to write arbitrary bytes.

1 Like
23

io::Write String can return "invalid data" error if buf given is not utf8

24

But what if somebody calls write_all with input that ends in the middle of a character?

1 Like
25

I think error should be returned. This behavior would be enough for format! needs, to my mind.

26

But splitting up a write into multiple calls should not change the results. Otherwise, something like BufWriter could not exist.

2 Likes
27

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.