9 ms·

I wish they would streamline the string handling capabilities. Currently the conversions between String and &str are really ugly to look at. In general the conv

I wish they would streamline the string handling capabilities. Currently the conversions between String and &str are really ugly to look at. In general the conversion between types don't seem all that great with developers having to either use crates or write their own code. They need to take more inspiration from C# which continues to be the benchmark of elegance (obviously personal opinion). That said, rust is still better than C++ - namely its package management is great. I just wish the compiler doesn't keep second guessing me :D

ChrisSD 6y ago
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
> the conversions between String and &str are really ugly to look at. This is entirely up to you; unless you find method calls ugly, in which case, you've got bigger problems :) > They need to take more inspiration from C# Could you elaborate a bit? I'm not familiar with what C# does here.
- option_greek 6y ago
  In C# there is a helper class: https://docs.microsoft.com/en-us/dotnet/api/system.convert?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.convert?v... I'm still figuring my way around rust so obviously some noob questions follow: -> what's with the move/copy mess ? I know why they are needed but it seem to be in the face with all the explicit '&' all over the place in any reasonably sized code. Why not hide it a bit by letting the implicit copy to happen to simpler structures ? (at compile time). -> Why no love for inheritance? :) - it makes certain patterns easier to implement -> Why no love for global/static variables ? I know they are prone to be misused but some patterns like singleton really need a lot of shortcuts to implement. And there will always be some cases where you want to keep variables with static and global scope
  - deleted 6y ago
    [deleted]
  - steveklabnik 6y ago
    Rust has From/Into and TryFrom/TryInto that do the same thing, as far as I can tell. It's not clear to me what the differences are, maybe someone else in this thread will know. :) > Why not hide it a bit by letting the implicit copy to happen to simpler structures ? This is the Copy trait. > Why no love for inheritance There are a variety of reasons, but one interesting one is that inheritance and strong type inference have issues, and we have very strong type inference. Beyond that, there are various other reasons, but what it really comes down to is that there's just not a ton of pressure to actually implement it; it's not enough of an impediment for Rust users to justify adding it. Most requests come from people who do not write Rust, and once people get into Rust and how it works, they don't seem to need it much anymore. This is of course very general and there are some people who love it and want it badly anyway, but "some people exist who want this feature" is not enough to make it happen. Rust already has a lot of features, and some people say too many. We have to be careful here. > Why no love for global/static variables ? What does "love" mean? Rust absolutely supports these.

ChrisSD 6y ago

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

> the conversions between String and &str are really ugly to look at. This is entirely up to you; unless you find method calls ugly, in which case, you've got bigger problems :) > They need to take more inspiration from C# Could you elaborate a bit? I'm not familiar with what C# does here.

option_greek 6y ago
In C# there is a helper class: https://docs.microsoft.com/en-us/dotnet/api/system.convert?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.convert?v... I'm still figuring my way around rust so obviously some noob questions follow: -> what's with the move/copy mess ? I know why they are needed but it seem to be in the face with all the explicit '&' all over the place in any reasonably sized code. Why not hide it a bit by letting the implicit copy to happen to simpler structures ? (at compile time). -> Why no love for inheritance? :) - it makes certain patterns easier to implement -> Why no love for global/static variables ? I know they are prone to be misused but some patterns like singleton really need a lot of shortcuts to implement. And there will always be some cases where you want to keep variables with static and global scope
- deleted 6y ago
  [deleted]
- steveklabnik 6y ago
  Rust has From/Into and TryFrom/TryInto that do the same thing, as far as I can tell. It's not clear to me what the differences are, maybe someone else in this thread will know. :) > Why not hide it a bit by letting the implicit copy to happen to simpler structures ? This is the Copy trait. > Why no love for inheritance There are a variety of reasons, but one interesting one is that inheritance and strong type inference have issues, and we have very strong type inference. Beyond that, there are various other reasons, but what it really comes down to is that there's just not a ton of pressure to actually implement it; it's not enough of an impediment for Rust users to justify adding it. Most requests come from people who do not write Rust, and once people get into Rust and how it works, they don't seem to need it much anymore. This is of course very general and there are some people who love it and want it badly anyway, but "some people exist who want this feature" is not enough to make it happen. Rust already has a lot of features, and some people say too many. We have to be careful here. > Why no love for global/static variables ? What does "love" mean? Rust absolutely supports these.