The fmt.Value api doesn't seem like an improvement over fmt.Sprintf("%v", v)

To me it looks ugly to call fmt.Sprintf from within fmt.Print (or fmt.Sprint). There's precedent for this in the standard library, strconv.FormatInt and strconv.FormatFloat also duplicate the functionality of fmt.Sprintf

I'm not clear on why fmt.Value is needed. What is the difference between fmt.Sprint(x) and fmt.Sprint(fmt.Value(x))?

I don't think it's a good idea for fmt.Error to automatically wrap error values. There are many cases where it is appropriate to use fmt.Errorf with %v for an error value. Wrapping an error is only appropriate when the new error in some sense is an instance of the wrapped error. It's not appropriate when the error merely refers to some other error.

I'm not clear on why fmt.Value is needed. What is the difference between fmt.Sprint(x) and fmt.Sprint(fmt.Value(x))?

In this case, none, the primary reason is to allow access through fmt.Print to formatting values like %#v, %+v and %#+v do, which at the moment isn't possible without using fmt.Printf. The secondary reason would be to disable automatic insertion of spaces.

I don't think it's a good idea for fmt.Error to automatically wrap error values. There are many cases where it is appropriate to use fmt.Errorf with %v for an error value

In those cases one can call the Error method directly.

In those cases one can call the Error method directly.

To be clear, I think the default should be %v, and %w should be the one that requires special action.

I do broadly agree that error wrapping is the case that should be explicit, but I wonder if choosing to call fmt.Error instead of fmt.Sprint is a sufficiently-special action to justify the different behavior for this common case.

Perhaps it would be harder to accidentally misuse if renamed and constrained a little more tightly:

• Name it WrapError instead of just Error.
• Require the last argument to implement error and disallow any other argument from implementing error.

The second of these is tricky in practice because there's no way to write a variadic signature whose last argument is more constrained than those before it, and so it would need to be declared as WrapError(...any) and impose the type constraints dynamically at runtime. This seems error-prone. I think this would also be the only place in fmt where a value implementing error is forbidden rather than automatically converted to a string using the Error method.

I also considered WrapError(error, ...any) so the error goes first and the prefix components go after, with the result then being the stringified any arguments followed by ": " and then the string representation of the error. But of course that means the arguments are in a different order to how they will appear in the final error string, which seems confusing.

As someone who admitted in the other issue that I don't know why I've been using Sprintf instead of Sprint I do find it plausible that part of the reason is that in practice I'm actually more often using fmt.Errorf, testing.T.Errorf (and similar), and log.Printf than fmt.Sprintf directly. And of those, fmt.Errorf is probably the most common and is therefore encouraging me to use the "f" versions of the others too out of habit.

All of those except fmt.Errorf do have a fmt.Sprint-like equivalent, and so I do quite like the idea of having a fmt.Sprint-like equivalent to fmt.Errorf, but it seems tricky to design in a way that will be self-explanatory to potential users and give good feedback when not used correctly. I'm also unsure about the other proposed features aside from fmt.Error.

Therefore I feel ambivalent about this proposal; I like the idea of it but the details don't feel quite right yet.

I disagree that fmt.Printf should be discouraged over fmt.Print. The helpers suggested here provide essentially the non-f form of Errorf, an implementation of %T (which can also just be reflect.TypeOf), and an implementation of %v. It's unclear why code would call these much longer names instead of writing a printf format. The semantics of Error with respect to Unwrap are also problematic: we used %w as an explicit signal that the error should unwrap. The default %v does not. So Error, if it did exist, should not automatically unwrap to any errors passed in.

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

I wrote this because it seemed like there would be interest based on the discussion about string interpolation but it doesn't look like anyone is interested in a simpler syntax for that, besides string interpolation itself.

I'd say everything should be considered retracted besides fmt.Error, which makes sense to me for symmetry.

It doesn't seem like there is enough support for fmt.Error (without f), and we probably don't also want fmt.Errorln.

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

Fair enough.

I'm not a fan of this proposal itself, but this was a great discussion and a cool methodology to start it off! Thanks @aarzilli

This proposal has been declined as retracted.
— rsc for the proposal review group