-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ffi::OsString and OsStr #21488
Add ffi::OsString and OsStr #21488
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
Note, this is work in progress and should not be merged until the RFC is accepted. cc @SimonSapin |
/// Yield a `&str` slice if the `OsStr` is valid unicode. | ||
/// | ||
/// This conversion may entail doing a check for UTF-8 validity. | ||
pub fn to_str(&self) -> Option<&str> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to_str => as_str?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, this can do work (UTF-8 validation).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What use is this function? Either you want a string to display, or you don't care about a string. What does it help if you get an Option<&str>
except for errornous code that assumes that all pathes are representable as UTF-8?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's akin to http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html -- basically, there may be cases where you do indeed expect the string to be UTF-8 but you don't want to panic if it's not, you want to handle the error more gracefully. By providing an Option
here we combine the checking and the coercion, a very common pattern in std
.
@alexcrichton Pushed an update addressing most of the issues. I didn't add Also, as I think I mentioned on IRC, the |
use sys_common::{AsInner, IntoInner, FromInner}; | ||
|
||
/// Owned, mutable OS strings. | ||
#[derive(Show, Clone)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could Show
be manually implemented instead of derived? (it should delegate to the slice)
Just a few nits here and there, but otherwise r=me, can't wait for this to start getting implemented! |
@bors r=alexcrichton e659d55 |
⌛ Testing commit e659d55 with merge 77ecfa3... |
💔 Test failed - auto-win-64-opt |
@bors: r=alexcrichton e7850b5 |
⌛ Testing commit e7850b5 with merge 9d4358a... |
💔 Test failed - auto-win-64-nopt-t |
@bors: r=alexcrichton dc6cd4c |
⌛ Testing commit dc6cd4c with merge f14b6ab... |
💔 Test failed - auto-mac-64-opt |
Per [RFC 517](rust-lang/rfcs#575), this commit introduces platform-native strings. The API is essentially as described in the RFC. The WTF-8 implementation is adapted from @SimonSapin's [implementation](https://github.com/SimonSapin/rust-wtf8). To make this work, some encodign and decoding functionality in `libcore` is now exported in a "raw" fashion reusable for WTF-8. These exports are *not* reexported in `std`, nor are they stable.
Per [RFC 517](rust-lang/rfcs#575), this commit introduces platform-native strings. The API is essentially as described in the RFC. The WTF-8 implementation is adapted from @SimonSapin's [implementation](https://github.com/SimonSapin/rust-wtf8). To make this work, some encodign and decoding functionality in `libcore` is now exported in a "raw" fashion reusable for WTF-8. These exports are *not* reexported in `std`, nor are they stable.
Per RFC 517, this commit introduces platform-native strings. The API is essentially as described in the RFC.
The WTF-8 implementation is adapted from @SimonSapin's implementation. To make this work, some encodign and decoding functionality in
libcore
is now exported in a "raw" fashion reusable for WTF-8. These exports are not reexported instd
, nor are they stable.