4 ms·

I'm not sure what you mean by conversion between String and &str? To get an owned String from a &str you just use the `into` method, no?

steveklabnik 6y ago
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.
- ChrisSD 6y ago
  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.
  - steveklabnik 6y ago
    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.
    - ChrisSD 6y ago
      Yeah sorry, I'm just really confused about what's being asked for.
- option_greek 6y ago
  -> 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).
  - steveklabnik 6y ago
    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 https://news.ycombinator.com/item?id=8704318
  - shadow31 6y ago
    > 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.

steveklabnik 6y ago

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.

ChrisSD 6y ago
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.
- steveklabnik 6y ago
  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.
  - ChrisSD 6y ago
    Yeah sorry, I'm just really confused about what's being asked for.
option_greek 6y ago
-> 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).
- steveklabnik 6y ago
  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 https://news.ycombinator.com/item?id=8704318
- shadow31 6y ago
  > 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.