Tracking Issue for explicit-endian String::from_utf16 (original) (raw)
Feature gate: #![feature(str_from_utf16_endian)]
This is a tracking issue for versions of String::from_utf16 which take &[u8] and use a specific endianness.
Public API
impl String { fn from_utf16le(v: &[u8]) -> Result<String, FromUtf16Error>; fn from_utf16le_lossy(v: &[u8]) -> String; fn from_utf16be(v: &[u8]) -> Result<String, FromUtf16Error>; fn from_utf16be_lossy(v: &[u8]) -> String; }
Steps / History
- Implementation: Add explicit-endian String::from_utf16 variants #95967
- Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
- Ideal naming; options include
from_utf16le,from_utf16_le,from_le_utf16,from_le_utf16_bytes, and other such combinations. - Should these methods get the
with_capacity+pushimplementation used forfrom_utf16whilecollectdoesn't reserve capacity? (Collecting into a Result<Vec<_>> doesn't reserve the capacity in advance #48994) - Tweaks to the error type:
FromUtf16Errorcurrently displays as"invalid utf-16: lone surrogate found"which isn't correct for an error due to odd byte length.- The
from_utf16method takes&[u16]so can't have the odd-length problem that&[u8]can.
- The