cc @SimonSapin
cc #504

👍

The fmt::Writer trait can also be located as io::TextWriter instead to emphasize its possible future connection with I/O, although there are not concrete plans today to develop these connections.

It is unclear to what degree a fmt::Writer needs to interact with io::Writer and the various adaptors/buffers. For example one would have to implement their own BufferedWriter for a fmt::Writer.

I think it’s fine for this trait to be in std::fmt. My current plan is to consider it an implementation detail of formatting, experiment on crates.io with separate traits for general-purpose Unicode streams, and if that proves successful propose adding them to std at some point after Rust 1.0. Then, std::fmt::Writer could (maybe, if it’s compatible) become a re-export of std::io::TextWriter (or whatever it’ll end up being named.)

I seem to remember from way back when I was working on the base64 and hex modules that push_char was significantly slower than push_byte. Would it be worth adding an unsafe write_u8 as well for things like {, ,, etc? Note that I haven't actually checked that this is still the case :)

I'd probably be more in favor of an unsafe function to go from &'a u8 to &'a str and then calling write_str instead, would you be ok with that?

@sfackler Looks like String::push (formerly push_char) doen’t have a fast path for ASCII (single-byte) code points. Would that help?

Also, if the char/byte is literal, how does .push_str("{") (with a &str of length 1) compare?

@SimonSapin I'd imagine that'd help, but I ran into this like ~1.5 years ago so my memory's a bit rusty :)

@alexcrichton Yeah, implementations just transmuting from &[u8] to &str seems fine for now.

@sfackler You can always used str::from_utf8_unchecked, but that seems unnecessary for the example you gave where you can just have a "{" string literal. (As opposed to '{'.)

Could it be confusing for newcomers for the stdlib to have two traits called Writer? Having to check to see which is in use, etc.

@Sgeo I think we more or less have a convention to take advantage of the namespacing provided by modules and not try to duplicate it within names. Rather than have use std::fmt::Writer; and later use Writer (which is unclear), you can (and maybe should) have use std::fmt; and then use fmt::Writer.

This RFC, which represents a longstanding request to enforce a strong Unicode convention and appears to have no real downsides, has been accepted. Tracking issue.

I notice that in the "after" benchmark, .to_string() is still about 3x slower for small strings. Can we do anything about the remaining overhead?