[ENH] Explore direct typed decoding for large JSON payloads

[tazarov]

Problem

Parser.Parse plus the DOM API is a good fit for selective reads, but consumers that must construct a complete typed response currently need to write and maintain a bespoke DOM-to-struct mapper. That makes adoption harder for large, nested query/search payloads, where avoiding an intermediate map[string]any tree could be a meaningful performance and allocation win.

Proposed exploration

Explore an opt-in typed-decoding layer that maps a JSON payload directly into a caller-defined Go result shape, without first materializing a generic Go tree.

The eventual API does not need to mimic encoding/json.Unmarshal exactly. Candidates include:

• a reusable compiled decoder for a declared Go shape;
• a visitor or callback-based API for user-controlled materialization; or
• generated decoders for known response schemas.

Desired properties

• Works with deeply nested arrays and objects, not only scalar projections.
• Preserves explicit handling for omitted fields, null, numeric precision, and malformed input.
• Can use a ParserPool safely under concurrent request load.
• Keeps encoding/json as a straightforward fallback; this should be opt-in rather than a global replacement.
• Does not require full map[string]any materialization on the fast path.
• Has benchmarks using large, nested response-shaped fixtures and reports Go plus native allocation metrics.

Why now

Large JSON responses are common in query/search workloads. The existing DOM and scalar batch-extraction capabilities show the underlying parse path is promising; a supported typed materialization path would make that performance practical for SDK integrations.

Out of scope

• Replacing the standard library for every JSON use case.
• Changing the existing DOM API.
• Claiming end-to-end speedups before application-shaped benchmarks are available.