To clarify, I don't think we should add the String method to the fmt.State interface — just to the implementation that the fmt package itself passes to Format methods.

(In retrospect I think it was a mistake to make State an interface in the first place, but given how early the fmt package was designed I can understand how that mistake could have been made at the time. 😅)

Technically we can't add a method to the fmt.State interface. But we can add a String method to the underlying type fmt.pp. Retitling.

CC @robpike

But we can add a String method to the underlying type fmt.pp. Retitling.

What would that let us do, though? Where I am imagining this would be most useful is in third party code that is inside of a Format() function call:

func (b myType) Format(w fmt.State, verb rune) {
    // here
}

The general shape of that function, I would imagine, is something like the other proposal:

1. Implement some of the verbs and flags with my custom behavior.
2. For the rest of them, invoke fmt.Fprintf(w, ???, b) or similar.

where ??? is, in theory, the recovered passed in format string.

If w is a fmt.pp under the hood, I don't think I can cast it to a fmt.Stringer or a fmt.pp there, can I? Sorry for being dense.

edit: ahhh... if we added String() you could do fmt.Sprint(w fmt.State) or whatever and recover the original string. Which is indirect but still gets us what we want.

@ianlancetaylor presumably it'd look like:

func (b myType) Format(w fmt.State, verb rune) {
   type derivedType myType
   fmt.Fprintf(w, w.String(), derivedType(b))
}

(that would mask any myType.String method though, and %T and %#v fallbacks wouldn't display the right type name, but otherwise, it'd be a generally feasible approach)

That said, I believe #51195 (comment) is cleaner.

Perhaps we could just document that when fmt.State receives no writes, it'll just re-interpret the value as though it were not a fmt.Formatter, and proceed accordingly (thus the "fallback" would merely be returning from the Format method without the fmt.State.Write method having been called).

I'm not sure we should be adding invisible methods here. The solution proposed in #51195 is completely visible - it doesn't need people to know things that aren't in the type system. A new method you type-assert would be different.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

One possibility is to have a top-level function from fmt.State to string, like

package fmt
func FormatString(State) string

Change https://go.dev/cl/400875 mentions this issue: fmt: add a function to recover the original format string given a State

@knz implemented https://github.com/knz/go-fmtfwd with some difficulty to work around this very issue.

@robpike has posted a CL at https://go-review.googlesource.com/c/go/+/400875. The API is almost what I wrote earlier, adding 'verb rune' to the argument list:

package fmt
func FormatString(state State, verb rune) string

This provides access to what was requested, just without a new State method.

Does anyone object to this API?

Actually it's not quite the same. The actual change is

package fmt
func FormatString(state State, verb rune) string

as State does not contain the verb. The verb is always at the end, so the caller could add it, but doing it here can remove an allocation.

No, because State is an interface.

Updated comment to record 'verb rune' in API.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group