Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mfridman opened this issue Sep 23, 2019 · 3 comments
Closed

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

mfridman opened this issue Sep 23, 2019 · 3 comments

Comments

@mfridman
Copy link

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
Copy link
Contributor

martisch commented Sep 23, 2019

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.

@martisch martisch added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Sep 23, 2019
@ianlancetaylor
Copy link
Contributor

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

@mfridman
Copy link
Author

mfridman commented Sep 24, 2019

@gopherbot, please remove WaitingForInfo

@martisch martisch removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Sep 24, 2019
@golang golang locked and limited conversation to collaborators Sep 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants