Change:
Cow::Owned(res) } <ins> /// Converts a [`Vec<u8>`] to a `String`, substituting invalid UTF-8 /// sequences with replacement characters. /// /// See [`from_utf8_lossy`] for more details. /// /// [`from_utf8_lossy`]: String::from_utf8_lossy /// /// Note that this function does not guarantee reuse of the original `Vec` /// allocation. /// /// # Examples /// /// Basic usage: /// /// ``` /// #![feature(string_from_utf8_lossy_owned)] /// // some bytes, in a vector /// let sparkle_heart = vec![240, 159, 146, 150]; /// /// let sparkle_heart = String::from_utf8_lossy_owned(sparkle_heart); /// /// assert_eq!(String::from("💖"), sparkle_heart); /// ``` /// /// Incorrect bytes: /// /// ``` /// #![feature(string_from_utf8_lossy_owned)] /// // some invalid bytes /// let input: Vec<u8> = b"Hello xF0x90x80World".into(); /// let output = String::from_utf8_lossy_owned(input); /// /// assert_eq!(String::from("Hello �World"), output); /// ``` #[must_use] #[cfg(not(no_global_oom_handling))] #[unstable(feature = "string_from_utf8_lossy_owned", issue = "129436")] pub fn from_utf8_lossy_owned(v: Vec<u8>) -> String { if let Cow::Owned(string) = String::from_utf8_lossy(&v) { string } else { // SAFETY: `String::from_utf8_lossy`'s contract ensures that if // it returns a `Cow::Borrowed`, it is a valid UTF-8 string. // Otherwise, it returns a new allocation of an owned `String`, with // replacement characters for invalid sequences, which is returned // above. unsafe { String::from_utf8_unchecked(v) } } } </ins> /// Decode a UTF-16–encoded vector `v` into a `String`, returning [`Err`] /// if `v` contains any invalid data. ///

Discussion:
If you have a of utf8 data there's three ways to get a : There doesn't appear to be any way to hand over the existing and have any necessary character changes into be done in place_. The type doesn't, for example, have a way to just do a lossy in-place conversion.
- I would like to implement this (I have no contributions yet in the project). May i please claim the request?
I think that normally the Libs team is given a chance to comment on the issue (it's only been 3 hours), but the worst that can happen is that they reject your PR. All I can say for sure is that I will not be implementing this particular patch myself.
Thanks for letting me know, I will wait until someone from the lib team will respond.
Seems like the right API here is actually , since I believe there is never a need to allocate more bytes. Unfortunately I guess we'd need two APIs for this to be perfect, one on String as well, since there's no safe way to get from running this function to a of the bytes, right? The only safe way would be to do which is guaranteed to succeed but is costly...
1) I don't want slice to slice. I definitely want owned to owned. I'm not sure why you'd think that slice to slice is somehow more correct. My goal is that whenever possible no additional allocations will immediately happen during the conversion (obviously this isn't always possible). 2) You definitely can have byte sequences where the lossy conversion into utf8 makes the sequence longer and thus could hit the capacity of the allocation and thus could trigger a reallocation. Trivial example: becomes , which is longer.
Hm, I had thought that the lossy conversion always replaced a single byte with a single byte, if that's not the case then the slice case is indeed not all that helpful probably. If this was true then the slice case would be good to have as a more general form, though.
So we want this signature: , right? That seems like it can be via a PR relatively easily.
That is one option. Another would be to add a method to so that you can consume that error into the lossy String. The value here is not having to start over on the utf8 parsing.

There was a post with possible designs on internals:
I hope gets soon :)
I prefer this approach for a couple of reasons. It signals whether or not the conversion was lossless. Whereas if we went with the signature , some pairs of inputs collide, like the pair and , or the pair and . Also, it will deter people from checking for the presence of to tell if something went wrong. This is a footgun I've seen in the wild. And even for users who "just want a string" and don't care about the error, you can still reasonably get that in single readable line: