seems to work with primitive types like pointers to bool/string/int, but not for composite types like slices, maps, and structs.

cc @robpike

The cited documentation is irrelevant to the issue, as you can see if you try the program without taking the address of the struct: you see the same behavior.

Now the question is, should the formats recur into the fields of a struct? They do not, and doing so would rarely be the right thing to do. Whether the documentation needs work here I'm not sure, but the paragraph you cite is irrelevant, as I said.

Have a look at https://go.dev/play/p/HnO93o9-oao

The particular problem cited in this issue is that formats propagate for integer values but not strings, although as the example shows it would be rarely useful for them to do so.

That's probably fixable, but also probably not worthwhile.

the format also works for books and strings though
https://go.dev/play/p/MSCt54fX00c
I think the expectation is that it doesn't look into the value, just print the pointer address

The cited documentation is irrelevant to the issue

Sorry, there might be a misunderstanding. The original title for the report was "fmt: Pointer formatting behavior doesn't match documentation". I don't have an opinion how the code should behave, just it doesn't behave as documented.

if you try the program without taking the address of the struct: you see the same behavior

A struct value is not a pointer; so the section "Pointer:" doesn't apply, and the section below that called "For compound objects, ..." applies, that's consistent.

If you think the code is working as intended, I'm fine with that. In that case I suggest the following changes to the documentation (emphasis on the changes):

Pointer:
%p base 16 notation, with leading 0x
The %b, %d, %o, %x and %X verbs also work with pointers to non-compound objects,
formatting the value exactly as if it were an integer.

and below

For compound objects, and pointers to compound objects, the elements are printed using these rules, ...