fmt: invoke String() / GoString() and Format() on unexported fields

[novas0x2a]

First, I'll say up front that this is a Feature Request.

What version of Go are you using (go version)?

go version go1.7.4 linux/amd64

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

This is a model of the problem: https://play.golang.org/p/_JsORLfYwk
Basically, I have an Ugly object which is an implementation detail of a Pretty object; Pretty does not export the ugly field because it's purely an implementation detail, and other packages don't need to know.

In the real version of this, I implemented fmt.Formatter on Ugly, but for simplicity here I've implemented String() since it exhibits the same behavior. I implemented Formatter so that when Ugly objects are printed into logs, they provide sufficient information for debugging (instead of just unhelpful pointer spam).

What did you expect to see?

The String() version of Pretty.ugly to be printed.

What did you see instead?

The undebuggable pointer spam version of Pretty.ugly.

This has come up before (gonuts thread / #17409 / #16698 / 4b9490e) but here I'm actually requesting a direct method of accomplishing this. A few workarounds exist:

1. You can implement fmt.Formatter on every type which holds an unexported field which implements fmt.Formatter and have your higher-level Formatter call the hidden one.
2. You can optimize the above slightly with two copies of the type (as mentioned in the gonuts thread: https://play.golang.org/p/5wGsFY3Fpc)
3. You can export every field which implements a useful String() or Format()

None of these workarounds are very satisfying, though. I understand why the problem exists (fmt, being a different package, can't see the full versions of the unexported fields) but it seems like this situation compromises the usefulness of Stringer, GoStringer, and Formatter- these interfaces are front-line debug tools, and having to choose between "debuggable log messages" and "only export the minimum" I'd generally choose the former every time.

Thanks!

[minux]

This is impossible to do without using unsafe as it's limited by the reflect package (you can't call methods on unexported fields.) That said, there are some go-gettable packages out there that use unsafe to get this done. e.g. https://godoc.org/github.com/davecgh/go-spew/spew

[robpike]

This would require too much low-level work to belong in the standard library to support a rare case. As @minux says, reach outside the core library for this one.