fmt: clarify precision for strings and slices

[jiceathome]

What is the URL of the page with the issue?

https://pkg.go.dev/fmt

What is your user agent?

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36

Screenshot

What did you do?

fmt.Printf("%8s", "ab")
fmt.Printf("%8s", "abcdefghijklmn")

What did you expect to see?

ab
abcdefgh

What did you see instead?

      ab
abcdefghijklmn

Problem is this phrase: "For strings, byte slices and byte arrays, however, precision limits the length of the input to be formatted (not the size of the output), truncating if necessary. ". The reality is the exact opposite. "%8s" will cause the output to padded with space; and not the input to be truncated. Either behavior is useful, but the doc states the wrong one.

[gabyhelp]

Related Issues

• fmt: Precision for strings formatting matches documented neither for %x nor %q #8151 (closed)
• x/pkgsite: incorrect rendering of old doc comments #53759 (closed)
• fmt: inconsistent padding of integers with and without f.sharp #14616 (closed)

Related Code Changes

• fmt: documentation correction
• fmt: restore padding for %x on byte slices and strings

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

I think it's working as intended https://go.dev/play/p/oAQwpK_XpSf
The format is %[width[.precision]]s, you've given width but not precision.

[jiceathome]

I wasn't talking about the behaviour. I was talking about the doc. The paragraph I mentioned only discusses width and is describing the behavior that you tell me is controlled by precision. I can go read the code if I want to know the truth, but I shouldn't need to.

[seankhliao]

the docs mention both, the example you gave just doesn't correspond to the part you worked.

For most values, width is the minimum number of runes to output, padding the formatted form with spaces if necessary.

For strings, byte slices and byte arrays, however, precision limits the length of the input to be formatted (not the size of the output), truncating if necessary.

[jiceathome]

Ah yes, the phrase is indeed referring to precision. Not width. I was led by the previous paragraph into reading this as contrasting the role of width in string/slice/... vs "most values". Might I suggest a more short-attention-span friendly phrasing?
"In addition, for strings, byte slices and byte arrays, the length of the input to be formatted (not the size of the output) is limited by precision, truncating if necessary." However, I agree that the paragraph is technically correct as it is.