Strings implement a lot of different conversions, since they're very general. You've got:

* Into, with s.into()

* An inherent method, .as_str()

* Deref coercion, &s

* Reborrowing, &*s (this builds on Deref too but isn't a coercion and can be done in places where coercion doesn't kick in)

... and probably some others I'm forgetting.

Right but as a general rule you'll mostly only be using `s.into()` to get a `String` from an `&str`. Or `&s` to deref `String` to a `&str`. I'm not sure why this would require a crate to handle?

The other ways are more "advanced", for when you're dealing with (for example) potentially unsafe coercions or you don't want to rely on inference for some reason.

I agree with you that I'm not sure what your parent is talking about, I'm just here to give all the examples. Deref coercion takes 99% of my String -> &str conversions, and I reborrow for that rare 1%, personally.

Yeah sorry, I'm just really confused about what's being asked for.

-> specifically this one: "Reborrowing, &*s"

Would have been easier to implement with a copy constructor I guess. Why not implicitly clone in some cases (since classes like String gets used so frequently).

Well, Rust doesn't have constructors, let alone copy constructors. Clone goes from &T -> T, so that is the exact opposite conversion needed here, let alone auto-clone.

Automatically copying strings may not be a great idea: https://news.ycombinator.com/item?id=8704318

> Why not implicitly clone in some cases (since classes like String gets used so frequently)

Because they get used so frequently. Why would we want to add expensive clones to frequently used operations?

This would be like asking why LINQ methods in C# aren't deferred by default. Yes, there's a few situations where that would be nice but it would make the functions largely useless because of how poor performance would be.