4 ms·

Is that not the point? That you ought to map out that complexity in a type whose constraints must be satisfied in order to have a valid instance? If your strin

Is that not the point? That you ought to map out that complexity in a type whose constraints must be satisfied in order to have a valid instance? If your string is invalid to start with and you need to correct it, then yes, you need to wrangle that complexity yourself. If you need some tools from another toolset - eg. String functions that can help you make a valid Path - then you will make multiple type conversion hops to arrive at your destination. But trying to use String methods on something that may not be a valid string is no solution to the original problem, and would merely be hoping you could get away with the assumption.

pjmlp 7y ago
The point is that should be part of the standard library, like wstring in C++.
- Fellshard 7y ago
  https://doc.rust-lang.org/std/ffi/struct.OsString.html https://doc.rust-lang.org/std/ffi/struct.OsString.html I'm puzzled what you think is missing. What should be part of the stdlib that isn't currently?
  - deleted 7y ago
    [deleted]
  - klodolph 7y ago
    Basic stuff like starts_with() is missing. You cannot slice an OsString into parts or iterate over its components. Almost everything you want to do with a string is missing. If you are curious for yourself, try to write an argument parser that will parse something like "--output=<path>" and store the path as an OsString, and make it work on both Linux and Windows. The OsString abstraction breaks, and you have to write platform-specific code or use "unsafe", even though internally OsString is just a Vec<u8> and you should be able to strip off the "--output" as it is encoded the same on both platforms. E.g., fill in the blank: /// Split an arg "--<name>=<value>" into (<name>, <value>). fn parse_arg(arg: &OsStr) -> Option<(&str, &OsStr)> { // What goes here? } This is trivial with &str.
    - Fellshard 7y ago
      Why not transfer it over to a full String instead? How many other libraries and core functions expect an OsString? Why rely on an abstraction that's intentionally been given minimal functionality? Of course `starts_with` is missing: you haven't resolved what underlying type the value actually is yet, and you'd be trying to compare apples and oranges for all you know! Move the OsString to a concrete type and you'll have all that functionality and more. The only time that will fail you is if you don't have a valid string to begin with, under which case `starts_with` should fail, correct? Everything about OsString makes it a type you convert to and from, but it's not intended to be one you work /in/, since that would make require you to make assumptions about which platform you are running on. You really want to manipulate it? Go to String and back, and pay the cost. This should also encourage you to use OsString as little as possible, at the edges.

pjmlp 7y ago

The point is that should be part of the standard library, like wstring in C++.

Fellshard 7y ago
https://doc.rust-lang.org/std/ffi/struct.OsString.html https://doc.rust-lang.org/std/ffi/struct.OsString.html I'm puzzled what you think is missing. What should be part of the stdlib that isn't currently?
- deleted 7y ago
  [deleted]
- klodolph 7y ago
  Basic stuff like starts_with() is missing. You cannot slice an OsString into parts or iterate over its components. Almost everything you want to do with a string is missing. If you are curious for yourself, try to write an argument parser that will parse something like "--output=<path>" and store the path as an OsString, and make it work on both Linux and Windows. The OsString abstraction breaks, and you have to write platform-specific code or use "unsafe", even though internally OsString is just a Vec<u8> and you should be able to strip off the "--output" as it is encoded the same on both platforms. E.g., fill in the blank: /// Split an arg "--<name>=<value>" into (<name>, <value>). fn parse_arg(arg: &OsStr) -> Option<(&str, &OsStr)> { // What goes here? } This is trivial with &str.
  - Fellshard 7y ago
    Why not transfer it over to a full String instead? How many other libraries and core functions expect an OsString? Why rely on an abstraction that's intentionally been given minimal functionality? Of course `starts_with` is missing: you haven't resolved what underlying type the value actually is yet, and you'd be trying to compare apples and oranges for all you know! Move the OsString to a concrete type and you'll have all that functionality and more. The only time that will fail you is if you don't have a valid string to begin with, under which case `starts_with` should fail, correct? Everything about OsString makes it a type you convert to and from, but it's not intended to be one you work /in/, since that would make require you to make assumptions about which platform you are running on. You really want to manipulate it? Go to String and back, and pay the cost. This should also encourage you to use OsString as little as possible, at the edges.