Ignoring for the moment any discussion of the need for the proposed functionality, it might suffice to implement some flags for the %w verb, which I don't believe accepts any at the moment.

See also #25675 and #27020.

%w accepts the same flags as %v.

Is the proposed %j the same as %.0w?

e1 := errors.New("1")
e2 := fmt.Errorf("2%.0w", e1)
fmt.Printf("%q", e2)
// "2"

Yes it's the same behaviour, to be honest I didn't know that flag on %w and it looks more like a kind of trick imo.

It's not clear to me where this proposal would be useful.

If the error is coming from a third-party library (or even the standard library), what's their motivation for using %j instead of %w? Most clients are just going to log the error as-is instead of recursively unwrapping it, meaning that any use of %j will exclude the original source of the error. So in all likelihood, they will always use %w. That means you cannot get your stack-trace-like behavior from third-party errors. (Plus there's also the matter of them having their own error types, which would be in a similar boat.)

If the error is coming from your own code, then you can just use your own error type instead of fmt.Errorf to get what you want. For example:

type wrappedError struct {
    message string
    err error
}

func (we wrappedError) Error() string {
    return we.message
}

func (we wrappedError) Unwrap() error {
    return we.err
}

func WrapError(message string, err error) error {
    return wrappedError{message: message, err: err}
}

func updateProfile() error {
	if err := storeProfile(); err != nil {
		return WrapError("can't update profile", err)
	}
	return nil
}

There's also the option to just put a newline in your format string, which might be sufficient for what you are trying to do anyway.

func updateProfile() error {
	if err := storeProfile(); err != nil {
		return fmt.Errorf("can't update profile\n%w", err)
	}
	return nil
}

Using %j instead of %w allow to :

• Use errors.Is() without exposing the error message due to security concerns.
• Print the error stack as I did on my first message. Useful for a web server if you log all the errors from a middleware. In a web server there is a lot of information to log and the result is unreadable.

This seems too special. If you want custom semantics, it is easy to write a function or error implementation that creates those semantics. %w answers a fundamental question: does it unwrap or not. I don't think %j has a place here: it doesn't even format.

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

func storeProfile() error {
	if err := writeOnDisk(); err != nil {
		return fmt.Errorf("can't store profile %w", err)
	}

When wrapping an error (which you should definitely always do!) you should provide context which is not already available to the caller. In this case "store profile" is what the caller has called, so it's not useful as an error prefix. Instead, that prefix should be "can't write on disk" which is information that the caller has no access to. And every prefix should in general terminate with a colon, so in this case return fmt.Errorf("write on disk: %w", err). This produces output which is clear.

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

func storeProfile() error {
	if err := writeOnDisk(); err != nil {
		return fmt.Errorf("can't store profile %w", err)
	}

When wrapping an error (which you should definitely always do!) you should provide context which is not already available to the caller. In this case "store profile" is what the caller has called, so it's not useful as an error prefix. Instead, that prefix should be "can't write on disk" which is information that the caller has no access to. And every prefix should in general terminate with a colon, so in this case return fmt.Errorf("write on disk: %w", err). This produces output which is clear.

What about errors that wrap multiple errors ? Should we use multiple prefix ? It'll look very messy.

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