Motivation
When integrating pure-simdjson as an alternate JSON parser behind a library that must preserve exact numeric semantics (e.g. distinguishing 1.0 from 1, and integers outside [-2^53, 2^53]), the consuming library's own numeric classifier typically keys off the raw source text — the way encoding/json does via json.Number (Decoder.UseNumber()).
Today Element exposes only GetInt64(), GetUint64(), GetFloat64(), and Type(). There is no way to retrieve the original number literal as it appeared in the input.
This forces integrators into type-driven routing off Type(), which reintroduces a subtle parity hazard: a whole-valued float like 1.0 or 1e18 arrives as TypeFloat64 with no signal that it was written with a ./e, so a classifier that folds whole floats to ints (or the reverse) silently diverges from the encoding/json reference for the same input.
Request
Add a raw-number accessor on Element, e.g.:
func (e Element) NumberRaw() ([]byte, error) // or RawJSON() ([]byte, error) for any scalar
returning the exact source slice for a number element (TypeInt64 / TypeUint64 / TypeFloat64, and ideally the BIGINT / ErrPrecisionLoss cases where typed accessors can't represent the value).
Why this is cheap
The raw bytes are already present in the parsed buffer/tape — surfacing a slice into it is O(1) and allocation-free (no re-serialization). It adds nothing to the fast path for callers who don't use it.
Use case
Lets integrators route all numbers through their own text classifier and preserve exact numeric semantics without reconstructing literals from typed accessors — eliminating ErrPrecisionLoss / BIGINT special-casing entirely for parity-sensitive consumers.
Motivation
When integrating
pure-simdjsonas an alternate JSON parser behind a library that must preserve exact numeric semantics (e.g. distinguishing1.0from1, and integers outside[-2^53, 2^53]), the consuming library's own numeric classifier typically keys off the raw source text — the wayencoding/jsondoes viajson.Number(Decoder.UseNumber()).Today
Elementexposes onlyGetInt64(),GetUint64(),GetFloat64(), andType(). There is no way to retrieve the original number literal as it appeared in the input.This forces integrators into type-driven routing off
Type(), which reintroduces a subtle parity hazard: a whole-valued float like1.0or1e18arrives asTypeFloat64with no signal that it was written with a./e, so a classifier that folds whole floats to ints (or the reverse) silently diverges from theencoding/jsonreference for the same input.Request
Add a raw-number accessor on
Element, e.g.:returning the exact source slice for a number element (
TypeInt64/TypeUint64/TypeFloat64, and ideally the BIGINT /ErrPrecisionLosscases where typed accessors can't represent the value).Why this is cheap
The raw bytes are already present in the parsed buffer/tape — surfacing a slice into it is O(1) and allocation-free (no re-serialization). It adds nothing to the fast path for callers who don't use it.
Use case
Lets integrators route all numbers through their own text classifier and preserve exact numeric semantics without reconstructing literals from typed accessors — eliminating
ErrPrecisionLoss/ BIGINT special-casing entirely for parity-sensitive consumers.