Skip to content
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

String::from_utf16_lossy signature differs from from_utf8_lossy #32874

Closed
starkat99 opened this issue Apr 11, 2016 · 5 comments
Closed

String::from_utf16_lossy signature differs from from_utf8_lossy #32874

starkat99 opened this issue Apr 11, 2016 · 5 comments
Assignees
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one. P-low Low priority

Comments

@starkat99
Copy link
Contributor

String::from_utf8_lossy returns a Cow<'a, str> while String::from_utf16_lossy returns simply String. It would be useful for their signature to both match. String::from_utf16_lossy should return Cow<'a, str> as well, though this is obviously a breaking, but easily solved, change.

@bluss
Copy link
Member

bluss commented Apr 11, 2016

The conversion from utf-16 can never result in a &str, since the representation of the data changes from using u16 units to u8.

@nagisa
Copy link
Member

nagisa commented Apr 11, 2016

Moreover you can trivially convert an owned datatype to Cow with into:

let x: Cow<str> = String::from_utf16_lossy(&[]).into();

@alexcrichton
Copy link
Member

Yeah unfortunately these signatures can't change (as they're stable), but they're both intended to return "string-like types" in whichever way is most suitable, but perhaps the docs can be bolstered up to emphasize that!

@steveklabnik steveklabnik added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed A-libs labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools and removed T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jun 16, 2017
@Mark-Simulacrum
Copy link
Member

Relabeling as a docs issue since we can't change these APIs. However, I'm not entirely sure what needs to be changed here. Specifically, we should mention that conversion from UTF-16 can never be done without allocating, so we don't return a Cow. I'm personally not sure this is a good idea, but I can see the benefits, since it explains the API inconsistency.

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 25, 2017
@steveklabnik steveklabnik added the P-low Low priority label Aug 30, 2017
@frewsxcv frewsxcv self-assigned this Sep 13, 2017
@frewsxcv
Copy link
Member

Opened a PR for this: #44572

frewsxcv added a commit to frewsxcv/rust that referenced this issue Sep 14, 2017
frewsxcv added a commit to frewsxcv/rust that referenced this issue Sep 15, 2017
… r=QuietMisdreavus

Clarify return type of `String::from_utf16_lossy`.

Fixes rust-lang#32874
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one. P-low Low priority
Projects
None yet
Development

No branches or pull requests

7 participants