Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/rust-lang/rust/issues/116258 below:

Tracking Issue for explicit-endian String::from_utf16 · Issue #116258 · rust-lang/rust · GitHub

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.

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;
}

• Implementation: Add explicit-endian String::from_utf16 variants #95967
• Final comment period (FCP)¹
• Stabilization PR

• 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+push implementation used for from_utf16 while collect doesn't reserve capacity? ( Collecting into a Result<Vec<_>> doesn't reserve the capacity in advance #48994)
• Tweaks to the error type: FromUtf16Error currently displays as "invalid utf-16: lone surrogate found" which isn't correct for an error due to odd byte length.
  • The from_utf16 method takes &[u16] so can't have the odd-length problem that &[u8] can.

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4