This feature could be the basis for more flexibility in the formatting capabilities of my github.com/go-stack/stack package.

It currently supports several useful formats for a call frame:

$ go doc github.com/go-stack/stack.Call.Format
package stack // import "github.com/go-stack/stack"

func (c Call) Format(s fmt.State, verb rune)
    Format implements fmt.Formatter with support for the following verbs.

        %s    source file
        %d    line number
        %n    function name
        %k    last segment of the package path
        %v    equivalent to %s:%d

    It accepts the '+' and '#' flags for most of the verbs as follows.

        %+s   path of source file relative to the compile time GOPATH
        %#s   full path of source file
        %+n   import path qualified function name
        %+k   full package path
        %+v   equivalent to %+s:%d
        %#v   equivalent to %#s:%d

But has only limited flexibility for slices of call frames:

$ go doc github.com/go-stack/stack.CallStack.Format
package stack // import "github.com/go-stack/stack"

func (cs CallStack) Format(s fmt.State, verb rune)
    Format implements fmt.Formatter by printing the CallStack as square brackets
    ([, ]) surrounding a space separated list of Calls each formatted with the
    supplied verb and options.

What about a fmt.ListFormatter[T] type? Used like:

fmt.Sprintf("%v", fmt.ListFormatter(list, opts))

opts TBD but allow for custom separators and the like. Each item in the list uses the specified formatting directive.

That probably wouldn't help with multierrors much but it would make it simpler to print prettier lists. It could be prototyped outside std using the regular formatter interface. Bringing it in to std would allow it to be lazy and reuse buffers.

I don't doubt the need, but I am not sure we can redefine these characters to be flags instead of verbs. For example https://go.dev/play/p/nVDu4H-e5GX.

It's true that on string it doesn't matter, but if we did fmt.Printf("%,v", customThing) and customThing had a Format method, then today Format gets called with verb = ','. Would it get called with verb = 'v' tomorrow? Or would the set of flags be different for things with Format methods and things without?

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

today Format gets called with verb = ','. Would it get called with verb = 'v'

That is indeed unfortunate, as it appears to freeze the set of flags.

It looks to me like we already (inadvertently?) made a breaking change to the set of verbs, though, with %w. From fmt/print.go:(*pp).handleMethods:

	if verb == 'w' {
		// It is invalid to use %w other than with Errorf, more than once,
		// or with a non-error arg.
		err, ok := p.arg.(error)
		if !ok || !p.wrapErrs || p.wrappedErr != nil {
			p.wrappedErr = nil
			p.wrapErrs = false
			p.badVerb(verb)
			return true
		}
		p.wrappedErr = err
		// If the arg is a Formatter, pass 'v' as the verb to it.
		verb = 'v'
	}

It looks like previous uses of %w with errors that implemented fmt.Formatter got altered to %v.

Maybe because it was so restricted in scope, but I don't recall seeing a single bit of fallout from that. fmt.Formatter is very sparsely used, and I would be very surprised to learn someone was using a non-letter verb with it, given the obvious pattern established by package fmt (non-letters for flags, letters for verbs).

All that said...

Or would the set of flags be different for things with Format methods and things without?

This seems like it would be the right choice (sadly). We would then document the exact set of flags compatible with fmt.Formatter.

This proposal looks sensible to me for basic types.

Perhaps a different proposal but how would it print slices of complex structs?

I threw together a quick proof of concept for using a generic fmt.Formatter to map the format string over a slice's elements https://go.dev/play/p/V-QsENTB4j3 (with special thanks to the CL for #51668). It doesn't have any configuration but that would be trivial to add.

I am still not sure about changing the flag semantics, nor about exactly where the line is for where we stop putting features into format strings. (Perhaps we've already crossed it.)

/cc @robpike

Fmt can't do everything. Other packages can, though.

I've added (perhaps too many) knobs to my proof of concept and published it for anyone who needs it: https://pkg.go.dev/github.com/jimmyfrasche/slicefmt

It sounds like maybe we've converged on not changing the standard library and instead focusing on other packages to provide this kind of thing. Do I have that right?

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

No change in consensus, so declined.
— rsc for the proposal review group