-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: behavior of pointer-like format arguments is undocumented #28865
Comments
This is even more confusing - here are some vet printf test cases:
So |
Will wait for some confirmation to send a CL, since I'm not 100% sure that vet is right and fmt is wrong about |
Why do you trust vet over fmt? Vet simulates fmt; the simulation is wrong. |
I'd hope that both fmt and vet implementations follow the fmt docs, which are ambiguous when it comes to formatting functions. Generally I'd trust the fmt implementation over vet's, but vet has had this check since 2015 (43a7a9c) and we've enforced it via That aside - @robpike, could you clarify if fmt's treatment of pointer-like types is as initially designed? If it is correct, then I'll just clarify the fmt docs and update vet to comply. |
Well, it's tricky. Both are right in this case, I believe. I wouldn't change either. When vet wasn't in the path to a build, this wasn't a problem. It's not clear it's a problem now, as in production code there is no likely story for printing a function, but it's certainly reasonable to print just about anything when debugging. |
This issue is about clarifying the fmt docs to be clear and precise, in which case either fmt's implementation or vet's would be wrong :)
I think there's an important distinction to make here. A verb like Isn't If on the other hand we think that changing fmt's behavior is unnacceptable, I think we're left with a hard decision. Leaving fmt's documentation ambiguous is bad, and losing the useful vet warnings is bad. |
Suggest what the documentation should say. I'd rather not change fmt's behavior; every time we do that it touches far more code than we expect and/or gets rolled back. |
That's a good point; we already got bit by that recently :) Perhaps all of these little fmt quirks could be fixed in a future v2 of the fmt package. |
Funcs and channels have one thing in common - they're all pointers underneath. This means one can use
%p
to print them, much like actual pointers.It's documented that
%b, %d, %o, %x and %X verbs also work with pointers
, so those can also be used for both funcs and channels too.But nowhere is it documented that channels and functions are treated as pointers when formatting. The closest thing is this piece:
I think we should extend the documentation to clarify a number of things:
%v
of a function is also%p
%p
That last point is especially tricky. For example,
fmt.Printf("%p", map[bool]bool{true: false}
will correctly print an address, but the same with%b
or%d
will fail asfmt
recurses into the key and value elements, which aren't numbers.I encountered this while fixing some bugs in vet, and I was surprised by how lightly
fmt
documents all this. A few of the behaviors surprised me too. I'll send a docs CL draft soon./cc @robpike @alandonovan @martisch
The text was updated successfully, but these errors were encountered: