CC @robpike

I'm not convinced either way. It seems odd to me that a correct output from %q would not include quotes, but "<nil>" is also clearly wrong.

It may be wisest to do nothing for most types and do something special only for the error type, where people are used to seeing nil in test output and such.

But it's a fiddly thing to do.

< and > in <nil> (kind of) serve as quotes in the nil case. As you said, using the "..." syntax (even "") would be clearly wrong, but <nil> signals that it's not even a valid string but just the plain nil.

As for the work, wouldn't it suffice to add 'q' and 's' in printArg?

I've also run into this issue in the past, and my initial suspicion was that was an issue in fmt package that needed to be fixed. I've spent more time investigating and considering what can be done, but in the end, I couldn't convince myself that there were any favorable changes that should be done in fmt itself. (Of course, it's possible I missed something that can be done.)

I instead modified the code to use %v in cases where the error might be nil, and reserved my use of %s (or %q) to cases where I've checked that it's not.

@robpike The catch is that since error is an interface type, a nil error gets converted to the empty interface as nil when calling fmt.Printf and friends. By the time that the fmt package sees the value, it's just a nil value of type interface{}, and the fact that it was once an error has been lost.

I'm not opposed to this change, and I'm also not enthusiastically in favor. My main concern at this point is the effect it will have on tests, as it could change golden output. It might be more disruptive than it's worth, but we can try it in the cycle if you like. As stated above, it's very easy to do. The challenge lies elsewhere.

@ianlancetaylor The package knows it's an error as it needs to check for the Error method, so it could be done there. But it's simpler and easier to explain if the change, should it happen, is done at the top of printArg.

@robpike I may be missing something but I think that in this case there is no way that the fmt functions can tell that the value was originally an error. https://play.golang.org/p/8xDEPCAqoFa

@ianlancetaylor I see what you mean. Let's make the conversation more confusing: https://play.golang.org/p/pVnlOIX1ArU

In any case, as I said most recently, it's probably best to do this for all types in printArg if we do it at all. I'd like some discussion about that, though, because it might be disruptive.