[WonderLawrence]

Add RawValue::from_string_unchecked

An unchecked counterpart of RawValue::from_string, for strings that are already known to be valid JSON — typically the output of another JSON serializer, or JSON that was validated once and cached.

Motivation

RawValue::from_string re-parses the entire input to establish the validity invariant. When the input is trusted by construction, that parse is pure overhead and becomes significant on hot paths that handle large payloads.

Concrete case: JSON-RPC servers (Ethereum execution clients such as reth and its forks) serve multi-megabyte, hot-cached or SIMD-serialized results. The only public way to embed such a payload today is from_string, whose validation scan claws back roughly a third of the serializer's gains — measured on x86_64/AVX2 for a 4 MB payload: serialize with sonic-rs 272 µs, then from_string validation 740 µs. jsonrpsee has the same redundant cost internally on every response it builds from its own serializer output (paritytech/jsonrpsee#1648).

Design

Follows the str::from_utf8 / str::from_utf8_unchecked precedent: the checked API stays the default, and the unsafe fn opts out of validation with the contract documented under # Safety — other code (including unsafe code) is allowed to rely on RawValue containing well-formed JSON, in the same way unsafe code may rely on str containing valid UTF-8.

Additive, no behavior change for existing APIs, gated behind the existing raw_value feature.

[dtolnay]

Thanks, this looks reasonable.

The "single well-formed JSON value" requirement makes sense but the "no leading or trailing whitespace" requirement might be a bit subtle. I expect many prospective callers might not realize if they have a trailing newline, such as a value coming from an include_str! where most text editors will fight you from trying to save the file without a trailing newline.

I think we should consider one of:

• Trim whitespace without validating JSON. This is O(1) in the common case of 0 leading whitespace and 0–1 trailing whitespace.
• Debug-assert the whitespace requirement.
• Debug-assert both requirements.

[WonderLawrence]

Thanks for the quick review!

I went with your third suggestion — a debug_assert! that covers both requirements at once. The check reuses crate::from_str::<&Self>(&json) and then compares borrowed.json.len() == json.len(); a successful parse gives the "single well-formed JSON value" invariant, and the length equality gives "no leading or trailing whitespace" (mirroring the branch already used in from_string). Release builds compile the assertion out, so the "no re-parse" property advertised in the doc still holds.

Why not option 1 (trim in the library):

• Leading whitespace can't be trimmed without either allocating a fresh String (defeats the zero-copy motivation) or an in-place drain(..n) (O(n) memmove). The include_str! / trailing-newline case is common, but leading-ws inputs are the ones that would silently regress performance, and there's no way at the API level to signal to the caller which happened.
• Absorbing whitespace also weakens the invariant that RawValue's bytes are byte-identical to what the caller passed in, which matters for callers who cache the string alongside the RawValue.

Why not option 2 (debug-assert whitespace only): the well-formedness violation is the strictly more severe failure mode (it corrupts the enclosing document, not just adds spaces), so checking only whitespace felt inverted. Doing both is essentially free — the parser walks the input once.

Two #[should_panic] tests were added to lock in the debug-build behavior for each of the two contract clauses.

[dtolnay]

Thanks!

[dtolnay]

Published in 1.0.151.