-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Implement TryFrom for CString and CStr #44916
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @BurntSushi (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
r? @sfackler |
Seems to be fixed with 526de507c81062905e2206eac06308cfe63a91a3. |
Thank you. Very useful 😄 |
I'm feeling a bit unsure about the UTF8 and UTF16 conversions - for |
cc @rust-lang/libs |
☔ The latest upstream changes (presumably #45233) made this pull request unmergeable. Please resolve the merge conflicts. |
Yo — @rust-lang/libs — it's been 16 days since we heard from all y'all. Care to chime in? |
These seem fine to me, @sfackler I don't have too many thoughts about the encoding question, it seems fine to me to take a conservative route and not add them for now. |
That'd limit it to the cstr impls then. |
Hello @nvzqz @rust-lang/libs — Is there a decision for this PR, that we limit to the CStr implementations?: // keep these:
impl<'a> TryFrom<&'a [u8]> for &'a CStr { … }
impl TryFrom<Vec<u8>> for CString { … }
impl TryFrom<CString> for String { … }
// and remove the rest? |
Makes sense to me. I'll make the appropriate changes later today. |
Hello from triage, @nvzqz! It's been a week since we last heard from you and it appears you've got some merge conflicts! Will you have some time to address those and the most recent feedback you received? |
@shepmaster just addressed these changes. Thanks for the reminder 😄 |
type Error = IntoStringError; | ||
|
||
fn try_from(c_str: CString) -> Result<String, IntoStringError> { | ||
c_str.into_string() |
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.
This checks for valid UTF-8 so this impl should also be removed.
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.
TryFrom<CString>
for String
is an obvious conversion. The underlying conversion checks valid UTF-8 but CString
is a named and obvious type unlike Vec<u8>
.
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.
A CString
is a sequence of none nul bytes. A Vec<u8>
is a sequence of bytes. The conversion to String
is exactly the same so it doesn't make sense to include one but not the other.
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.
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.
I'd lean towards leaving this out for now.
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.
CI failed...
src/libstd/ffi/c_str.rs
Outdated
@@ -646,6 +647,24 @@ impl From<CString> for Vec<u8> { | |||
} | |||
} | |||
|
|||
#[unstable(feature = "try_from", issue = "33417")] | |||
impl<T: Into<Vec<u8>>> TryFrom<T> for CString { |
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.
[00:02:22] error[E0119]: conflicting implementations of trait `core::convert::TryFrom<_>` for type `ffi::c_str::CString`:
[00:02:22] --> /checkout/src/libstd/ffi/c_str.rs:651:1
[00:02:22] |
[00:02:22] 651 | / impl<T: Into<Vec<u8>>> TryFrom<T> for CString {
[00:02:22] 652 | | type Error = NulError;
[00:02:22] 653 | |
[00:02:22] 654 | | fn try_from(t: T) -> Result<CString, NulError> {
[00:02:22] 655 | | CString::new(t)
[00:02:22] 656 | | }
[00:02:22] 657 | | }
[00:02:22] | |_^
[00:02:22] |
[00:02:22] = note: conflicting implementation in crate `core`
It is conflicting with impl<T, U> TryFrom<U> for T where T: From<U>
, because CString: Into<Vec<u8>>
, i.e. this overlaps with the identity transformation CString: TryFrom<CString>
.
Try to change it to impl TryFrom<Vec<u8>> for CString
and impl<'a> TryFrom<&'a [u8]> for CString
.
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.
Perhaps this should just be TryFrom<Vec<u8>>
instead. Only having the slice conversion results in a potentially unwanted allocation in the case of:
let vec = vec![/* ... */];
let c_str: CString = vec.try_into()?;
Hi @nvzqz, do you have time to fix the CI failure? |
Conversions: - Vec<u8> to CString - CString to String - &[u8] to &CStr
Review ping for you @sfackler ! |
@sfackler There is a question for you too on #44916 (review). |
@nvzqz I think the consensus here is to keep only the encoding-agnostic conversions |
There is also an inconsistency between the |
I'm nominating this PR to the @rust-lang/libs team. The consensus so far is removing every conversion involving string encodings, which leaves us with However, as #44916 (comment) pointed out, these two conversions are semantically incompatible in this current form. I can see several resolutions:
No matter which is picked, I don't think the author can proceed without further decisions. |
The fact that there is any debate over what the semantics of these impls may indicate we shouldn't add them. |
Triage ping @rust-lang/libs @sfackler! Any update on this PR? |
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.
We discussed these impls with the libs team. Regarding &[u8] ⟶ &CStr and Vec<u8> ⟶ CString we agreed on option 5 of Kenny's #44916 (comment) -- give up and don't add these as TryFrom implementations. We prefer for code to use the verbose but unambiguous named constructors like CStr::from_bytes_with_nul
if there is any question of what the impl does.
Feeling the need to document what the impl does is a sure sign that there is a question of what the impl does. From and TryFrom impls should never need explanatory documentation.
The &[u8] ⟶ &CStr conversion is the one that comes closest to meeting this bar. If someone understand the invariants of CStr and the implications of & ⟶ &, it really narrows it down to one possible thing the TryFrom impl could reasonably do. But even for that we felt it involves too much background knowledge and in practice the impl would need to be documented, so the conversion should not be handled by a TryFrom impl.
About CString ⟶ String we felt less strongly, but from reading the discussion here again I agree with the consensus of ruling this one out for the same reason as Vec<u8> ⟶ String.
As a secondary concern, we were skeptical about the motivation for adding any of these TryFrom impls. In general we felt that the existence of a Result<Self, Error> method does not necessary mean that an equivalent TryFrom impl needs to exist. We would have preferred for this to be motivated by a concrete API that someone wanted to write, some function where it makes sense to take T: TryInto<&'a CStr>
that cannot be expressed any other way that is as ergonomic for callers.
Thanks anyway for the PR and for the insightful discussion -- this is what helps figure out the role we want for TryFrom.
Implements
TryFrom
by utilizing the available conversions.This is a subset of #33417.
Conversions
&{mut,} [u8]
&{mut,} str
UTF-8Vec<u8>
String
UTF-8&[u16]
String
UTF-16&[u8]
&CStr
CString
String
Into<Vec<u8>>
CString
Motivation
These types already have conversions that return
Result<Self, Error>
. This simply implementsTryFrom
for such types.