[golang-dev] encoding/json: why are \n and \r escaped but \t, \b and \f aren't?

I am currently implementing a general fuzzer which I am testing on JSON
implementations. I stumbled upon a difference in Go's implementation which
made me curious. The current JSON RFC https://tools.ietf.org/html/rfc7159
defines some characters for strings which can be escaped with a backslash
instead of using the character's code point. E.g. The line feed character
can be written as "\n" instead of "\u000A". Go's implementation currently
escapes \, ", \n and \r but leaves out \b, \f and \t. I am wondering why?
Is it a performance issue?

I found the following CL https://codereview.appspot.com/4678046/ which
added escaping for \r and \n. \b and \f were intentionally left out with
the reason "no one cares about \f and more people know \b as word boundary
than as backspace". (I agree but it made me wonder why they are defined in
Go's language specification which does also conflict with the mentioned \b
as regex word boundary when used in an interpreted string. Maybe they
should be removed from the spec as well?) \t on the other hand was
mentioned but never included in the patch.

I do not have any common statistics to back this up but if \n and \r are
common enough to be included in encoding/json I suggest that \t should be
added too. Since this would reduce JSON encoding of one \t from 6 bytes to
2 which could be significant for servers who for example send source code.

I also found a mistake in encoding/json/encode.go. encodeState.stringBytes,
which is marked as "keep in sync with encodeState.string", has a comment
"// as well as < and >. The latter are escaped because they" which should
be "// as well as <, > and &. The latter are escaped because they".

Cheers
- Markus