fmt: priority of error and Stringer when handling non-simple types

[mfridman]

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

$ go version
go version devel +a11644a2 Wed Sep 18 21:30:35 2019 +0000 darwin/amd64

Does this issue reproduce with the latest release?

Yes (and on playground)

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

go env Output

$ go env
GOHOSTARCH="amd64"
GOHOSTOS="darwin"

What did you do?

Reproducible on playground here: https://play.golang.org/p/y4VFIJEgqOs

What did you expect to see?

I'd expect to see the priority of the type switch here to be reversed.

I.e., the first check should be "does it satisfy Stringer", followed "does it satisfy error"

Either way it'll lead to a panic when used as an embedded field, but, more often than not users will check errors before using them so making Stringer of higher priority would make the most common use-case the correct one.

There might be a reason to have error checked first, but it's not immediately obvious here.

[martisch]

I think this is very similar to the previously discussed and closed #25707.

Looks to be working as documented currently (https://golang.org/pkg/fmt/) and we would not be able to change it without breaking backwards compatibility.

4. If an operand implements the error interface, the Error method will be invoked to convert the object to a string, which will then be formatted as required by the verb (if any).

5. If an operand implements method String() string, that method will be invoked to convert the object to a string, which will then be formatted as required by the verb (if any).

If it is agreed to be working as documented for fmt do you want your report to be considered as a change proposal?

You could if wanted rewrite it a bit before to put more focus in the proposal on why the new way would better and worth potentially breaking existing code that should be rewritten. Maybe add more information by searching codebases github how often this problem can be seen in existing code and what the workarounds developed are that would be avoided or new ones needed to be added.

[ianlancetaylor]

Thanks for the report. This is working as documented and intended, so closing.

[mfridman]

@gopherbot, please remove WaitingForInfo