Tracking Issue for explicit-endian String::from_utf16 · Issue #116258 · rust-lang/rust (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Description

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+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.

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