Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
fmt: formatting of reflect.Value items inconsistent with documentation #16015
Please answer these questions before submitting your issue. Thanks!
So, in the following program (https://play.golang.org/p/V4H-vkjoE5):
I expect the first fmt.Printf call to substitute the concrete value of v, which is SpecialInt(73), invoke the String() method on it, and print "SpecialInt(73)". However, it just prints "73". On the contrary, the second fmt.Printf call (correctly) prints "SpecialInt(73)".
Is there anything I'm missing here, or maybe something wrong with the Go documentation or implementation?
There is a trivial fix to this that solves the test case but won't work in general. The code says
We could instead call
which would extract the interface and print that. This works but only if the value being printed was not acquired by using Value.Field of an unexported field.
We could write
and maybe that's the best we can do. Another possibility, maybe the right one, is to tweak the if at the top of printValue to know that the handle-methods check hasn't been done yet.
I think the
Added the depth check when refactoring reflect value printing https://go-review.googlesource.com/#/c/20923/.
As far as i recall currently:
If only the depth check is removed handleMethods is called twice for the default branch of printArg.
So the depth check addresses the CL comment about "slows down a very common operation" and to not slow down printValue for depth 0 either.
I will take a look for go 1.8 how we can ideally keep the performance for Stringer and still call handleMethods consistently once for reflect values.
Thanks for bringing this back to my attention. Was on vacation in september and sidetracked by some other patches. (I also was not able to assign myself to golang issues) I will do some measurements again and send a proposal CL with tests within a week so we have this fixed for 1.8.