rustc suggests calling to_string() on &&str but this generates inefficient code.

[ianloic]

If I write some code like:

fn stringify(s: &&str) -> String {
    s
}

then rustc will say something like:

1 | fn stringify(s: &&str) -> String {
  |                           ------ expected `String` because of return type
2 |     s
  |     ^- help: try using a conversion method: `.to_string()`
  |     |
  |     expected `String`, found `&&str`

(see: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c01bf377e97a0b1c90bd374ba90663a6)

But ToString::to_string() for &&str uses the default implementation which goes via fmt.

Even with optimization this is far less efficient than dereferencing the value first (eg: https://godbolt.org/z/rEoo1qv6x)

Ideally we'd have some better combination of an efficient to_string() override and better advice in error messages.

[the8472]

ToString already uses specialization (but it's not a specialization trait), it might be possible to add one for that case, though probably not a recursive one.

[workingjubilee]

It seems to me that rustc's suggestions are nonetheless an optimization over the status quo of the proposed original source code, as

fn stringify(s: &&str) -> String {
    s
}

generates this assembly

and a compiler error.

I am surprised that there is no other codegen issue with which this is a duplicate. I do not think we are going to predicate our diagnostics on the resulting codegen, either, as we cannot predict such, because we expose codegen settings that alter how well something will perform.