I would recommend to at least specify in the proposal:

• What should happen in the case of pointer-to-pointer (e.g. **T or ***T)?
• What should happen if the pointer is invalid (somehow points to an invalid address/non-existing object)? Should it panic or print something specific?
• What should happen if the pointer points to unmanaged memory (e.g. outside the go heap)?

Current fmt does already follow pointers but not past the first level because it is unclear what should happen in case of cycles? Depending on the answer it might also add alot of complexity to implement which might better be suitable for a different package.

What should this code print?

type T *T
var v T
v = &v
fmt.Printf("%V", v)

The %v format derefences one level deep already. The %V format would just indicate a preference for deeper dereferencing. Signs of trouble such as too deep nesting or cycles can be easily detected and formatting could fall back to its %v behavior then.

With that said here are answers to the questions above.

What should happen in the case of pointer-to-pointer (e.g. **T or ***T)?

It could print as them as &(&T{}) or &(&(&T{}))

What should happen if the pointer is invalid (somehow points to an invalid address/non-existing object)? Should it panic or print something specific?
What should happen if the pointer points to unmanaged memory (e.g. outside the go heap)?

It should follow the example of the one-deep dereferencing for %v

Current fmt does already follow pointers but not past the first level because it is unclear what should happen in case of cycles?
...
What should this code print?

It should detect a too deep (e.g. >= 5) nesting level and fall back to formatting as %v

Depending on the answer it might also add alot of complexity to implement which might better be suitable for a different package

Having it in the core would be nice already for logging, for matting of error messages and test results.

You may want to update the proposal to include (and expand on) all these details. Otherwise, people will have to read the whole thread to understand what you are proposing.

Good point. I updated the proposal accordingly.

I personally like the idea of using %*v since * is used for dereferencing. Although doing that we get into trouble with %+*v vs %*+v and such. I like this though, although I'm not sure.

Other considerations:

• Allow telling how deep you want the dereferencing to go, so you may still print deep pointers (%(*6)V or something? That looks gross but it gets the message across of what I'm illustrating)
• Instead of falling back to %v, perhaps print an error (ie %!V(TOODEEP=iterationnum))

I personally like the idea of using %*v since * is used for dereferencing.

The * is already taken for setting formatting precision and width indirectly.

• Allow telling how deep you want the dereferencing to go, so you may still print deep pointers (%(*6)V or something? That looks gross but it gets the message across of what I'm illustrating)

The * is already taken, but I like the idea of making it configurable, e.g. using the precision field of %V to specify the maximum depth, i.e.. %.6V would dereference up to six levels.

• Instead of falling back to %v, perhaps print an error (ie %!V(TOODEEP=iterationnum))

I like that idea, thanks!

So it's time to update the proposal with the two points:

• specifying maximum depth
  • either using the precision field
  • or keeping the %v precision semantic and set a fixed depth
• handling too deep nesting
  • either falling back to %v formatting
  • or printing an error %!V(TOODEEP=iterationnum)
    All points have their merits, so I'd like to have something like a poll. Not sure how to do it in this issue tracker though.

Since the rune %V is not used yet the proposed change is backwards compatible.

This is not strictly true. Other implementations of fmt.Formatter may be implementing %V.
This seems very special-case for taking up a whole separate letter. It's unclear where this ends.
%#v prints Go syntax. There's no Go syntax for the *int case other than what's already printed.

There are many ways the default printing might not satisfy one use case or another.
We can't attempt to satisfy them all in the print package.
Sorry.

Since the rune %V is not used yet the proposed change is backwards compatible.

This is not strictly true. Other implementations of fmt.Formatter may be implementing %V.

I don't agree with the non-compatibility argument: A type with an existing fmt.Formatter would use it the same as before (like all other builtin runes, e.g. v):

type MyInt int
func (my MyInt) Format(f fmt.State, c rune) { fmt.Fprintf(f,"%d",100-int(my)) }
func main() {
        my := MyInt(7)
        fmt.Printf("%v vs %v\n", my, int(my))
}

prints 93 vs 7, i.e. a fmt.Formatter overrules the builtin.

This seems very special-case for taking up a whole separate letter. It's unclear where this ends.
%#v prints Go syntax. There's no Go syntax for the *int case other than what's already printed.

The V would indicate that the value is much more important than any transient info such as a pointer. The concrete type information is already available via %T formatting. We could also decide not to support #V formatting for now.

Logging pointers is almost worthless in cloud deployments (i.e. multiple running instances that are restarted aplenty) whereas logging object values is really useful for analyzing problems across many runs.

There are many ways the default printing might not satisfy one use case or another.
We can't attempt to satisfy them all in the print package.
Sorry.

Fair enough. Thanks for considering the proposal.