Hi @lemire @jkeiser — I'd appreciate your thoughts on this approach.

Context: I'm building go-simdjson, a Go wrapper around simdjson's DOM API via CGo. BIGINT_ERROR is the only case where valid JSON (per RFC 8259, which places no limit on number magnitude) causes a DOM parse failure. Every other error code represents genuinely malformed input or a
resource limit. On Demand users can recover via raw_json_token(), but DOM users have no recovery path — the parse fails entirely on documents containing big integers.

What #2640 does: When parser.number_as_string(true) is set, visit_number catches BIGINT_ERROR and writes the raw digits to the string buffer with a BIGINT = 'Z' tape tag. Users read it back via element.get_bigint() which returns a string_view. Default behavior is completely unchanged — zero cost when disabled.

Design decisions I'd like your input on:

1. Runtime flag vs compile-time #ifdef: I used a runtime parser.number_as_string(bool) for ergonomics, but I know the project prefers compile-time options in hot paths. The check is only on the error path ( BIGINT_ERROR already returned), so the branch predictor should always skip it. Would you prefer #ifdef SIMDJSON_NUMBER_AS_STRING instead?

2. Re-scanning digits: After parse_number returns BIGINT_ERROR, I re-scan the digits with is_digit() to determine the length. parse_number already computed this but doesn't expose it. I considered passing
   the digit count back, but that would change parse_number's return type and affect On Demand. Is there a better way, or is the re-scan acceptable given big integers are rare and the data is L1-hot?

3. API naming: I used get_bigint() returning string_view and element_type::BIGINT. Open to alternatives — get_number_string(), get_raw_number(), etc. What feels right for the project?

4. Scope: Should this also handle numbers-as-strings more broadly (e.g., very large floats), or is big integer support sufficient for now?