Skip to content

Tracking issue for owned CString conversions #29157

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

Closed
alexcrichton opened this issue Oct 19, 2015 · 5 comments
Closed

Tracking issue for owned CString conversions #29157

alexcrichton opened this issue Oct 19, 2015 · 5 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@alexcrichton
Copy link
Member

This is a tracking issue for the into_foo methods being added in #28977. Some possible future questions to consider:

  • Is IntoStringError suitable? Named appropriately? Correct set of accessors? etc.
  • Should be paired with an Into implementation
@alexcrichton alexcrichton added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. labels Oct 19, 2015
@Diggsey
Copy link
Contributor

Diggsey commented Oct 25, 2015

Relatedly, I think the documentation for CString could be improved: it should make it explicit that CStrings do not have or enforce any specific encoding, they are simply null-terminated arbitrary byte sequences.

On the other hand, all of the conversion methods will implicitly assume that it is supposed to contain UTF8 data (an unfortunate decision IMO, but too late to change). It should therefore warn that the default conversions will not necessarily be what is required: users should look to the documentation of the C library they are interfacing with to determine what, if any, encoding is used for its strings.

@alexcrichton
Copy link
Member Author

🔔 This issue is now entering its final comment period for stabilization 🔔

@alexcrichton alexcrichton added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed I-nominated labels Dec 17, 2015
@BurntSushi
Copy link
Member

This looks OK to me. I would like to echo some of @Diggsey's thoughts. In particular, the docs could use improving. e.g., into_string should probably "UTF-8 data" instead of "Unicode data."

@alexcrichton
Copy link
Member Author

The libs team discussed this recently and the decision was to stabilize

@alexcrichton
Copy link
Member Author

Closed by #30943

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants