Extend useless_format to lint values other than &str and String

[ghost]

format!("{}", x) can be replaced by x.to_string() when x implements ToString . The new code is neater and probably faster.

[sinkuu]

format!("{}", x) can be unconditionally rewritten to x.to_stirng() thanks to the <T: Display> ToString for T blanket impl.

[oli-obk]

@RalfJung mentioned that they really dislike even changing format!("foo") to "foo".to_string() considering that they have the same perf nowadays and readability does not suffer at all. Quite the opposite: if you have 20 format! calls in a file and a few to_string sprinkled in between, that actually is worse than just having format! everywhere

[RalfJung]

Addendum: I dislike this in some cases. I think this is context-dependent. I use format! when this is similar to other nearby code (e.g. formatting error messages for the user, and there are a whole bunch of cases) -- consistency in multiple match branches increases readability a lot.

But when the intention is not to format user-visible text, but to e.g. turn an integer into a string, I will use i.to_string(). I think there is a different in intent between formatting and converting to a string, and it is useful to express that in the code.

[ghost]

Good point about <T:Display>.

So would this change be accepted? If not, should we do anything about the existing lint?

[sanmai-NL]

So,

format!("foo")

is worse at communicating intention than

"foo".to_owned()

[RalfJung]

That depends heavily on the context.

In Miri, we have some error types taking String, and then you frequently see code like

MachineError(format!("Unable to access {}", foobar))

but sometimes the message is just a string with no format variable, and then we write

MachineError(format!("Division by 0"))

I think this communicates intent much clearer than if we changed some of the error messages to use to_owned.

[sanmai-NL]

I think you're confusing consistency and/or the principle of least surprise with communicating intent there. And I happen to value the latter more than stylistic consistency.

[RalfJung]

Well, feel free to turn on that lint in your files then, but please don't make add it to a default lint.

And no, I don't think I am confusing this. The intent here is to create a string for consumption by the user -- the intent is to do formatting for UI output. The fact that the string being printed is a literal should not mean that I suddenly use entirely different syntax. The fact that the string must be owned to be put into a MachineError is a detail I couldn't care less about at this point, so to_owned conveys to useful information in this case.

[sanmai-NL]

But you're not formatting that literal at all in the case we're talking about. You would use an &str if you could, you just need to assert ownership of it.

[camsteffen]

Duplicate of #3156