Merge branch 'develop' into claude/todo-191-plan-508110

Resolve the conflict in docs/mkdocs/docs/home/architecture.md by taking
develop's rewritten page and pointing its ordered_map links at the moved
api/ordered_map/index.md. Also update the ordered_map.md links develop
added in ordered_json.md, object_order.md, and template_parameters.md.

Regenerate api_surface.json for the new BON8 functions and the changed
comparison operator. Restrict the documented_non_public leak check to
@sa URLs into json.nlohmann.me: develop now uses @sa to link GitHub
issues from private members such as copy_structured, which is not a
documentation leak.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

docs/mkdocs/docs/api/basic_json/accept.md

@@ -90,6 +90,10 @@ Linear in the length of the input. The parser is a predictive LL(1) parser.
 
 A UTF-8 byte order mark is silently ignored.
 
+By default, a `'\0'` (NUL) byte anywhere in the input is treated as end of input, rather than as an ordinary (and,
+outside of a string, invalid) byte; see the [FAQ entry](../../home/faq.md#nul-bytes-in-the-input) for details and the
+[`JSON_STRICT_NUL_HANDLING`](../macros/json_strict_nul_handling.md) macro to opt into rejecting it instead.
+
 ## Examples
 
 ??? example
@@ -111,6 +115,8 @@ A UTF-8 byte order mark is silently ignored.
 - [parse](parse.md) - deserialize from a compatible input
 - [sax_parse](sax_parse.md) - parse input using the SAX interface
 - [operator>>](../operator_gtgt.md) - deserialize from stream
+- [`JSON_STRICT_NUL_HANDLING`](../macros/json_strict_nul_handling.md) - opt in to rejecting a NUL byte in the input
+  instead of treating it as end of input
 
 ## Version history
 
@@ -120,6 +126,8 @@ A UTF-8 byte order mark is silently ignored.
 - Added `ignore_trailing_commas` in version 3.13.0.
 - Extended container support (1) to include types with lvalue-only ADL `begin`/`end` (matching `std::begin`/`std::end` semantics) in version 3.13.0.
 - Extended overload (2) to accept heterogeneous iterator+sentinel pairs (C++20 ranges support) in version 3.13.0.
+- `JSON_STRICT_NUL_HANDLING` added in version 3.13.0 to optionally reject a NUL byte in the input instead of treating
+  it as end of input; planned to become the default in version 4.0.0.
 
 !!! warning "Deprecation"
 

docs/mkdocs/docs/api/basic_json/array_t.md

@@ -14,7 +14,11 @@ To store objects in C++, a type is defined by the template parameters explained
 ## Template parameters
 
 `ArrayType`
-:   container type to store arrays (e.g., `std::vector` or `std::list`)
+:   container type to store arrays. It must be a vector-like container: the library uses `operator[]`, `at()`, and
+    `resize()`, and requires random-access iterators. `#!cpp std::vector` and `#!cpp std::deque` qualify;
+    `#!cpp std::list` does not. See
+    [Template Parameter Requirements](../../features/types/template_parameters.md#arraytype) for the full list of
+    requirements.
 
 `AllocatorType`
 :   the allocator to use for objects (e.g., `std::allocator`)
@@ -66,3 +70,4 @@ Arrays are stored as pointers in a `basic_json` type. That is, for any access to
 ## Version history
 
 - Added in version 1.0.0.
+- Made `capacity()` optional, so that array types such as `#!cpp std::deque` can be used, in version 3.13.0.

docs/mkdocs/docs/api/basic_json/binary_t.md

@@ -42,7 +42,9 @@ represent a byte array in modern C++.
     `value_type` must additionally be exactly one byte wide (e.g., `std::uint8_t`/`char`/`std::byte`): the binary
     serializers (CBOR, MessagePack, BSON, UBJSON) read and write the container's raw bytes via
     `reinterpret_cast`, which is only correct for byte-sized elements -- a container like
-    `#!cpp std::vector<std::intptr_t>` will not work as `BinaryType`.
+    `#!cpp std::vector<std::intptr_t>` will not work as `BinaryType`. The elements must be stored contiguously, and
+    the binary readers additionally require `resize()` and `operator[]`. See
+    [Template Parameter Requirements](../../features/types/template_parameters.md#binarytype) for the full list.
 
 ## Notes
 
@@ -50,6 +52,11 @@ represent a byte array in modern C++.
 
 The default values for `BinaryType` is `#!cpp std::vector<std::uint8_t>`.
 
+#### Supported byte types
+
+`#!cpp std::vector<std::uint8_t>`, `#!cpp std::vector<char>`, and `#!cpp std::vector<std::byte>` are supported.
+Regardless of which of them is configured, [`dump`](dump.md) writes the bytes as the numbers 0..255.
+
 #### Custom BinaryType behavior
 
 When a custom `BinaryType` is configured (other than the default `#!cpp std::vector<std::uint8_t>`), you can assign
@@ -126,3 +133,6 @@ type `#!cpp binary_t*` must be dereferenced.
 ## Version history
 
 - Added in version 3.8.0. Changed the type of subtype to `std::uint64_t` in version 3.10.0.
+- Fixed [`dump`](dump.md), [`std::hash`](std_hash.md), and [`to_ubjson`](to_ubjson.md) for byte types that are not
+  integers (e.g., `#!cpp std::byte`) in version 3.13.0. `dump` now writes the bytes of a signed byte type (e.g.,
+  `#!cpp char`) as 0..255 rather than as negative numbers.

docs/mkdocs/docs/api/basic_json/boolean_t.md

@@ -11,6 +11,14 @@ literals `#!json true` and `#!json false`.
 
 To store boolean values in C++, a type is defined by the template parameter  `BooleanType` which chooses the type to use.
 
+## Template parameters
+
+`BooleanType`
+:   the type to store booleans. As it is stored directly inside a `basic_json` value (in a union), it must be a
+    trivially default-constructible, trivially copyable, and trivially destructible type that is convertible to and
+    from `#!cpp bool`. See
+    [Template Parameter Requirements](../../features/types/template_parameters.md#booleantype).
+
 ## Notes
 
 #### Default type

docs/mkdocs/docs/api/basic_json/cbor_tag_handler_t.md

@@ -18,7 +18,7 @@ ignore
 :   ignore tags
 
 store
-:   store tagged values as binary container with subtype (for bytes 0xd8..0xdb)
+:   store tagged byte strings (for bytes 0xd8..0xdb) as binary values with the tag as subtype; other tagged values are read as if the tag were ignored. If several tags precede a byte string, only the innermost one is stored.
 
 ## Examples
 

docs/mkdocs/docs/api/basic_json/from_bjdata.md

@@ -104,6 +104,7 @@ Linear in the size of the input.
 - [from_msgpack](from_msgpack.md) create a JSON value from an input in MessagePack format
 - [from_bson](from_bson.md) create a JSON value from an input in BSON format
 - [from_ubjson](from_ubjson.md) create a JSON value from an input in UBJSON format
+- [from_bon8](from_bon8.md) create a JSON value from an input in BON8 format
 
 ## Version history
 

docs/mkdocs/docs/api/basic_json/from_bon8.md

@@ -0,0 +1,108 @@
+# <small>nlohmann::basic_json::</small>from_bon8
+
+```cpp
+// (1)
+template<typename InputType>
+static basic_json from_bon8(InputType&& i,
+                            const bool strict = true,
+                            const bool allow_exceptions = true);
+// (2)
+template<typename IteratorType, typename SentinelType = IteratorType>
+static basic_json from_bon8(IteratorType first, SentinelType last,
+                            const bool strict = true,
+                            const bool allow_exceptions = true);
+```
+
+Deserializes a given input to a JSON value using the BON8 (Binary Object Notation 8) serialization format.
+
+1. Reads from a compatible input.
+2. Reads from an iterator range, or an iterator and a sentinel of a different type (C++20 ranges support).
+
+The exact mapping and its limitations are described on a [dedicated page](../../features/binary_formats/bon8.md).
+
+## Template parameters
+
+`InputType`
+:   A compatible input, for instance:
+
+    - an `std::istream` object
+    - a `FILE` pointer
+    - a C-style array of characters
+    - a pointer to a null-terminated string of single byte characters
+    - a container `obj` for which `begin(obj)` and `end(obj)` produce a valid pair of iterators
+      (as found via ADL or member functions, with semantics compatible to `std::begin` and `std::end`)
+
+`IteratorType`
+:   a compatible iterator type
+
+`SentinelType`
+:   defaults to `IteratorType`; may be a different type comparable to `IteratorType` via `operator!=`, for instance.
+
+    - a custom sentinel type for C++20 ranges
+    - `std::default_sentinel_t`, when `IteratorType` is `std::counted_iterator`
+
+## Parameters
+
+`i` (in)
+:   an input in BON8 format convertible to an input adapter
+
+`first` (in)
+:   iterator to the start of the input
+
+`last` (in)
+:   iterator to the end of the input, or a sentinel value that compares equal to the end iterator with `operator!=`
+
+`strict` (in)
+:   whether to expect the input to be consumed until EOF (`#!cpp true` by default)
+
+`allow_exceptions` (in)
+:   whether to throw exceptions in case of a parse error (optional, `#!cpp true` by default)
+
+## Return value
+
+deserialized JSON value; in case of a parse error and `allow_exceptions` set to `#!cpp false`, the return value will be
+`value_t::discarded`. The latter can be checked with [`is_discarded`](is_discarded.md).
+
+## Exception safety
+
+Strong guarantee: if an exception is thrown, there are no changes in the JSON value.
+
+## Exceptions
+
+- Throws [parse_error.110](../../home/exceptions.md#jsonexceptionparse_error110) if the given input ends prematurely or
+  the end of the file was not reached when `strict` was set to true
+- Throws [parse_error.112](../../home/exceptions.md#jsonexceptionparse_error112) if a parse error occurs, for instance
+  an invalid byte, a string that is not valid UTF-8, or an object key that is not a string
+
+## Complexity
+
+Linear in the size of the input.
+
+## Examples
+
+??? example
+
+    The example shows the deserialization of a byte vector in BON8 format to a JSON value.
+     
+    ```cpp
+    --8<-- "examples/from_bon8.cpp"
+    ```
+    
+    Output:
+    
+    ```json
+    --8<-- "examples/from_bon8.output"
+    ```
+
+## See also
+
+- [to_bon8](to_bon8.md) create a BON8 serialization of a JSON value
+- [from_cbor](from_cbor.md) create a JSON value from an input in CBOR format
+- [from_msgpack](from_msgpack.md) create a JSON value from an input in MessagePack format
+- [from_bson](from_bson.md) create a JSON value from an input in BSON format
+- [from_ubjson](from_ubjson.md) create a JSON value from an input in UBJSON format
+- [from_bjdata](from_bjdata.md) create a JSON value from an input in BJData format
+
+## Version history
+
+- Added in version 3.13.0.

docs/mkdocs/docs/api/basic_json/from_bson.md

@@ -104,6 +104,7 @@ Linear in the size of the input.
 - [from_msgpack](from_msgpack.md) for the related MessagePack format
 - [from_ubjson](from_ubjson.md) for the related UBJSON format
 - [from_bjdata](from_bjdata.md) for the related BJData format
+- [from_bon8](from_bon8.md) for the related BON8 format
 
 ## Version history
 

docs/mkdocs/docs/api/basic_json/from_cbor.md

@@ -110,6 +110,7 @@ Linear in the size of the input.
 - [from_bson](from_bson.md) create a JSON value from an input in BSON format
 - [from_ubjson](from_ubjson.md) create a JSON value from an input in UBJSON format
 - [from_bjdata](from_bjdata.md) create a JSON value from an input in BJData format
+- [from_bon8](from_bon8.md) create a JSON value from an input in BON8 format
 
 ## Version history
 

docs/mkdocs/docs/api/basic_json/from_msgpack.md

@@ -103,6 +103,7 @@ Linear in the size of the input.
 - [from_bson](from_bson.md) create a JSON value from an input in BSON format
 - [from_ubjson](from_ubjson.md) create a JSON value from an input in UBJSON format
 - [from_bjdata](from_bjdata.md) create a JSON value from an input in BJData format
+- [from_bon8](from_bon8.md) create a JSON value from an input in BON8 format
 
 ## Version history
 

docs/mkdocs/docs/api/basic_json/from_ubjson.md

@@ -104,6 +104,7 @@ Linear in the size of the input.
 - [from_msgpack](from_msgpack.md) create a JSON value from an input in MessagePack format
 - [from_bson](from_bson.md) create a JSON value from an input in BSON format
 - [from_bjdata](from_bjdata.md) create a JSON value from an input in BJData format
+- [from_bon8](from_bon8.md) create a JSON value from an input in BON8 format
 
 ## Version history
 

docs/mkdocs/docs/api/basic_json/get_to.md

@@ -21,6 +21,10 @@ This overload is chosen if:
 - `ValueType` is not `basic_json`,
 - `json_serializer<ValueType>` has a `from_json()` method of the form `void from_json(const basic_json&, ValueType&)`
 
+`v` must not be `const`. Passing a `const` object is a compile-time error. For types such as arithmetic types, enums,
+and C arrays, the error is a `static_assert` that names the problem. For other types, the overload is not viable, and
+the compiler reports that no matching `get_to` was found.
+
 ## Template parameters
 
 `ValueType`
@@ -67,3 +71,4 @@ Depends on the `json_serializer<ValueType>::from_json()` implementation.
 ## Version history
 
 - Since version 3.3.0.
+- Added a `static_assert` with a clear message for `const` arguments in version 3.13.0.

docs/mkdocs/docs/api/basic_json/index.md

@@ -35,6 +35,10 @@ class basic_json;
 | `BinaryType`         | type for binary arrays                                                    | [`binary_t`](binary_t.md)                   |
 | `CustomBaseClass`    | extension point for user code                                             | [`json_base_class_t`](json_base_class_t.md) |
 
+The library imposes a number of requirements on these types that are not expressed as C++ concepts, such as the
+container operations `object_t` and `array_t` must provide, or the fact that `StringType` must be `char`-based. They
+are collected in [Template Parameter Requirements](../../features/types/template_parameters.md).
+
 ## Specializations
 
 - [**json**](../json.md) - default specialization
@@ -286,11 +290,13 @@ Access to the JSON value
 ### Binary formats
 
 - [**from_bjdata**](from_bjdata.md) (_static_) - create a JSON value from an input in BJData format
+- [**from_bon8**](from_bon8.md) (_static_) - create a JSON value from an input in BON8 format
 - [**from_bson**](from_bson.md) (_static_) - create a JSON value from an input in BSON format
 - [**from_cbor**](from_cbor.md) (_static_) - create a JSON value from an input in CBOR format
 - [**from_msgpack**](from_msgpack.md) (_static_) - create a JSON value from an input in MessagePack format
 - [**from_ubjson**](from_ubjson.md) (_static_) - create a JSON value from an input in UBJSON format
 - [**to_bjdata**](to_bjdata.md) (_static_) - create a BJData serialization of a given JSON value
+- [**to_bon8**](to_bon8.md) (_static_) - create a BON8 serialization of a given JSON value
 - [**to_bson**](to_bson.md) (_static_) - create a BSON serialization of a given JSON value
 - [**to_cbor**](to_cbor.md) (_static_) - create a CBOR serialization of a given JSON value
 - [**to_msgpack**](to_msgpack.md) (_static_) - create a MessagePack serialization of a given JSON value

docs/mkdocs/docs/api/basic_json/input_format_t.md

@@ -7,7 +7,8 @@ enum class input_format_t {
     msgpack,
     ubjson,
     bson,
-    bjdata
+    bjdata,
+    bon8
 };
 ```
 
@@ -31,6 +32,9 @@ bson
 bjdata
 :   BJData (Binary JData)
 
+bon8
+:   BON8 (Binary Object Notation 8)
+
 ## Examples
 
 ??? example

docs/mkdocs/docs/api/basic_json/insert.md

@@ -88,6 +88,8 @@ Strong exception safety: if an exception occurs, the original value stays intact
       do not belong to the same JSON value; example: `"iterators do not fit"`
     - Throws [`invalid_iterator.211`](../../home/exceptions.md#jsonexceptioninvalid_iterator211) if `first` or `last`
       are iterators into container for which insert is called; example: `"passed iterators may not belong to container"`
+    - Throws [`invalid_iterator.202`](../../home/exceptions.md#jsonexceptioninvalid_iterator202) if `first` or `last`
+      do not point to an array; example: `"iterators first and last must point to arrays"`
 4. The function can throw the following exceptions:
     - Throws [`type_error.309`](../../home/exceptions.md#jsonexceptiontype_error309) if called on JSON values other than
       arrays; example: `"cannot use insert() with string"`

docs/mkdocs/docs/api/basic_json/json_base_class_t.md

@@ -21,8 +21,11 @@ The default value for `CustomBaseClass` is `void`. In this case, an
 
 #### Limitations
 
-The type `CustomBaseClass` has to be a default-constructible class.
+The type `CustomBaseClass` has to be a default-constructible, non-`final` class.
 `basic_json` only supports copy/move construction/assignment if `CustomBaseClass` does so as well.
+A `CustomBaseClass` with non-static data members forfeits `basic_json`'s
+[standard layout](https://en.cppreference.com/w/cpp/named_req/StandardLayoutType) guarantee. See
+[Template Parameter Requirements](../../features/types/template_parameters.md#custombaseclass).
 
 ## Examples
 

docs/mkdocs/docs/api/basic_json/json_serializer.md

@@ -19,6 +19,12 @@ using json_serializer = JSONSerializer<T, SFINAE>;
 
 The default values for `json_serializer` is [`adl_serializer`](../adl_serializer/index.md).
 
+#### Requirements
+
+A custom serializer must provide `#!cpp static void to_json(basic_json&, T)` for every type it serializes, and either
+`#!cpp static void from_json(const basic_json&, T&)` or `#!cpp static T from_json(const basic_json&)` for every type it
+deserializes. See [Template Parameter Requirements](../../features/types/template_parameters.md#jsonserializer).
+
 ## Examples
 
 ??? example

docs/mkdocs/docs/api/basic_json/number_float_t.md

@@ -20,6 +20,16 @@ used.
 To store floating-point numbers in C++, a type is defined by the template parameter `NumberFloatType` which chooses the
 type to use.
 
+## Template parameters
+
+`NumberFloatType`
+:   the type to store floating-point numbers. Parsing and serialization are implemented in terms of
+    `#!cpp std::strtof`/`#!cpp std::strtod`/`#!cpp std::strtold` and `#!cpp std::snprintf`, so the type must be
+    `#!cpp float`, `#!cpp double`, or `#!cpp long double`. The
+    [binary formats](../../features/binary_formats/index.md) additionally require `#!cpp float` or `#!cpp double`,
+    because they have no encoding for `#!cpp long double`. See
+    [Template Parameter Requirements](../../features/types/template_parameters.md#numberfloattype).
+
 ## Notes
 
 #### Default type

docs/mkdocs/docs/api/basic_json/number_integer_t.md

@@ -20,6 +20,13 @@ used.
 To store integer numbers in C++, a type is defined by the template parameter `NumberIntegerType` which chooses the type
 to use.
 
+## Template parameters
+
+`NumberIntegerType`
+:   the type to store signed integers. It must be a **signed integral** type (`#!cpp std::is_integral`) with a
+    `#!cpp std::numeric_limits` specialization, and it is stored directly inside a `basic_json` value. See
+    [Template Parameter Requirements](../../features/types/template_parameters.md#numberintegertype-and-numberunsignedtype).
+
 ## Notes
 
 #### Default type

docs/mkdocs/docs/api/basic_json/number_unsigned_t.md

@@ -20,6 +20,14 @@ used.
 To store unsigned integer numbers in C++, a type is defined by the template parameter `NumberUnsignedType` which chooses
 the type to use.
 
+## Template parameters
+
+`NumberUnsignedType`
+:   the type to store unsigned integers. It must be an **unsigned integral** type (`#!cpp std::is_integral`) with a
+    `#!cpp std::numeric_limits` specialization, and it must be able to represent the absolute value of every
+    [`number_integer_t`](number_integer_t.md) value. See
+    [Template Parameter Requirements](../../features/types/template_parameters.md#numberintegertype-and-numberunsignedtype).
+
 ## Notes
 
 #### Default type

docs/mkdocs/docs/api/basic_json/object_comparator_t.md

@@ -30,3 +30,5 @@ and [`default_object_comparator_t`](default_object_comparator_t.md) otherwise.
 - Added in version 3.0.0.
 - Changed to be conditionally defined as `#!cpp typename object_t::key_compare` or `default_object_comparator_t` in
   version 3.11.0.
+- Fixed the fallback to `default_object_comparator_t`, which previously failed to compile for object types without a
+  `key_compare` member type, in version 3.13.0.

docs/mkdocs/docs/api/basic_json/object_t.md

@@ -18,7 +18,11 @@ To store objects in C++, a type is defined by the template parameters described
 ## Template parameters
 
 `ObjectType`
-:   the container to store objects (e.g., `std::map` or `std::unordered_map`)
+:   the container to store objects. Its template parameters must have the same order and meaning as those of
+    `std::map`; in particular, the third parameter is a comparator. `#!cpp std::unordered_map`, whose third parameter
+    is a hash function, therefore needs an adapter -- see
+    [Template Parameter Requirements](../../features/types/template_parameters.md#objecttype) for the full list of
+    requirements, an adapter example, and the containers that are known to work.
 
 `StringType`
 :   the type of the keys or names (e.g., `std::string`). The comparison function `std::less<StringType>` is used to
@@ -122,3 +126,4 @@ the object is silently converted as an array of key-value pairs, which is incorr
 ## Version history
 
 - Added in version 1.0.0.
+- Allowed object types whose `erase(iterator)` returns `#!cpp void` in version 3.13.0.

docs/mkdocs/docs/api/basic_json/parse.md

@@ -103,6 +103,10 @@ A UTF-8 byte order mark is silently ignored.
 Invalid Unicode escapes and unpaired surrogates in the input are reported as
 [`parse_error.101`](../../home/exceptions.md#jsonexceptionparse_error101) with a detailed message.
 
+By default, a `'\0'` (NUL) byte anywhere in the input is treated as end of input, rather than as an ordinary (and,
+outside of a string, invalid) byte; see the [FAQ entry](../../home/faq.md#nul-bytes-in-the-input) for details and the
+[`JSON_STRICT_NUL_HANDLING`](../macros/json_strict_nul_handling.md) macro to opt into rejecting it instead.
+
 ## Examples
 
 ??? example "Parsing from a character array"
@@ -236,6 +240,8 @@ Invalid Unicode escapes and unpaired surrogates in the input are reported as
 - [accept](accept.md) - check if the input is valid JSON
 - [sax_parse](sax_parse.md) - parse input using the SAX interface
 - [operator>>](../operator_gtgt.md) - deserialize from stream
+- [`JSON_STRICT_NUL_HANDLING`](../macros/json_strict_nul_handling.md) - opt in to rejecting a NUL byte in the input
+  instead of treating it as end of input
 
 ## Version history
 
@@ -246,6 +252,8 @@ Invalid Unicode escapes and unpaired surrogates in the input are reported as
 - Added `ignore_trailing_commas` in version 3.13.0.
 - Extended container support (1) to include types with lvalue-only ADL `begin`/`end` (matching `std::begin`/`std::end` semantics) in version 3.13.0.
 - Extended overload (2) to accept heterogeneous iterator+sentinel pairs (C++20 ranges support) in version 3.13.0.
+- `JSON_STRICT_NUL_HANDLING` added in version 3.13.0 to optionally reject a NUL byte in the input instead of treating
+  it as end of input; planned to become the default in version 4.0.0.
 
 !!! warning "Deprecation"
 

docs/mkdocs/docs/api/basic_json/parse_error.md

@@ -5,7 +5,7 @@ class parse_error : public exception;
 ```
 
 The library throws this exception when a parse error occurs. Parse errors can occur during the deserialization of
-JSON text, BSON, CBOR, MessagePack, UBJSON, as well as when using JSON Patch.
+JSON text, BJData, BON8, BSON, CBOR, MessagePack, UBJSON, as well as when using JSON Patch.
 
 Member `byte` holds the byte index of the last read character in the input file (see note below).
 

docs/mkdocs/docs/api/basic_json/sax_parse.md

@@ -65,11 +65,14 @@ The SAX event lister must follow the interface of [`json_sax`](../json_sax/index
 :   SAX event listener (must not be null)
 
 `format` (in)
-:    the format to parse (JSON, CBOR, MessagePack, or UBJSON) (optional, `input_format_t::json` by default), see
+:    the format to parse (JSON, BJData, BON8, BSON, CBOR, MessagePack, or UBJSON) (optional, `input_format_t::json` by
+     default), see
      [`input_format_t`](input_format_t.md) for more information
 
 `strict` (in)
-:   whether the input has to be consumed completely (optional, `#!cpp true` by default)
+:   whether the input has to be consumed completely (optional, `#!cpp true` by default); when `#!cpp false` and the
+    input is a `#!cpp std::istream`, the character that terminates a number is consumed unless
+    [`JSON_PRECISE_STREAM_POSITION`](../macros/json_precise_stream_position.md) is defined to `1`; see [`operator>>`](../operator_gtgt.md#notes)
 
 `ignore_comments` (in)
 :   whether comments should be ignored and treated like whitespace (`#!cpp true`) or yield a parse error
@@ -136,6 +139,8 @@ A UTF-8 byte order mark is silently ignored.
 - Added `ignore_trailing_commas` in version 3.13.0.
 - Extended container support (1) to include types with lvalue-only ADL `begin`/`end` (matching `std::begin`/`std::end` semantics) in version 3.13.0.
 - Extended overload (2) to accept heterogeneous iterator+sentinel pairs (C++20 ranges support) in version 3.13.0.
+- `JSON_PRECISE_STREAM_POSITION` added in version 3.13.0 to optionally leave a `#!cpp std::istream` positioned right
+  after the parsed value when `strict` is `#!cpp false`.
 
 !!! warning "Deprecation"
 

docs/mkdocs/docs/api/basic_json/string_t.md

@@ -23,6 +23,11 @@ JSON class into byte-sized characters during deserialization.
     `StringType`. To work with wide-character data, convert it to/from UTF-8 at the boundary instead -- see the
     FAQ's [wide string handling](../../home/faq.md#wide-string-handling) section for a conversion recipe.
 
+    Beyond the character type, the library expects a substantial part of the `#!cpp std::string` interface (contiguous
+    null-terminated `data()`, `substr()`, `find()`, `append()`, ...). See
+    [Template Parameter Requirements](../../features/types/template_parameters.md#stringtype) for the full list and
+    for the string types that are known to work.
+
 ## Notes
 
 #### Default type
@@ -78,3 +83,5 @@ and an example.
 ## Version history
 
 - Added in version 1.0.0.
+- Removed the requirement that `string_t` be implicitly convertible from `#!cpp std::string`, which the BSON writer and
+  the UBJSON reader relied on, in version 3.13.0.

docs/mkdocs/docs/api/basic_json/to_bjdata.md

@@ -84,6 +84,7 @@ Linear in the size of the JSON value `j`.
 - [to_msgpack](to_msgpack.md) create a MessagePack serialization of a JSON value
 - [to_bson](to_bson.md) create a BSON serialization of a JSON value
 - [to_ubjson](to_ubjson.md) create a UBJSON serialization of a JSON value
+- [to_bon8](to_bon8.md) create a BON8 serialization of a JSON value
 
 ## Version history
 

docs/mkdocs/docs/api/basic_json/to_bon8.md

@@ -0,0 +1,76 @@
+# <small>nlohmann::basic_json::</small>to_bon8
+
+```cpp
+// (1)
+static std::vector<std::uint8_t> to_bon8(const basic_json& j);
+
+// (2)
+static void to_bon8(const basic_json& j, detail::output_adapter<std::uint8_t> o);
+static void to_bon8(const basic_json& j, detail::output_adapter<char> o);
+```
+
+Serializes a given JSON value `j` to a byte vector using the BON8 (Binary Object Notation 8) serialization format. BON8
+is a compact binary serialization format that stores strings as UTF-8 without a length prefix.
+
+1. Returns a byte vector containing the BON8 serialization.
+2. Writes the BON8 serialization to an output adapter.
+
+The exact mapping and its limitations are described on a [dedicated page](../../features/binary_formats/bon8.md).
+
+## Parameters
+
+`j` (in)
+:   JSON value to serialize
+
+`o` (in)
+:   output adapter to write serialization to
+
+## Return value
+
+1. BON8 serialization as a byte vector
+2. (none)
+
+## Exception safety
+
+Strong guarantee: if an exception is thrown, there are no changes in the JSON value `j`, which is never modified.
+With (2), the bytes written before the exception remain in the output adapter.
+
+## Exceptions
+
+- Throws [out_of_range.407](../../home/exceptions.md#jsonexceptionout_of_range407) if `j` contains an unsigned integer
+  above 9223372036854775807, which BON8 cannot represent
+- Throws [type_error.316](../../home/exceptions.md#jsonexceptiontype_error316) if `j` contains a string that is not
+  valid UTF-8
+
+## Complexity
+
+Linear in the size of the JSON value `j`.
+
+## Examples
+
+??? example
+
+    The example shows the serialization of a JSON value to a byte vector in BON8 format.
+     
+    ```cpp
+    --8<-- "examples/to_bon8.cpp"
+    ```
+    
+    Output:
+    
+    ```json
+    --8<-- "examples/to_bon8.output"
+    ```
+
+## See also
+
+- [from_bon8](from_bon8.md) create a JSON value from an input in BON8 format
+- [to_cbor](to_cbor.md) create a CBOR serialization of a JSON value
+- [to_msgpack](to_msgpack.md) create a MessagePack serialization of a JSON value
+- [to_bson](to_bson.md) create a BSON serialization of a JSON value
+- [to_ubjson](to_ubjson.md) create a UBJSON serialization of a JSON value
+- [to_bjdata](to_bjdata.md) create a BJData serialization of a JSON value
+
+## Version history
+
+- Added in version 3.13.0.

docs/mkdocs/docs/api/basic_json/to_bson.md

@@ -46,9 +46,8 @@ Strong guarantee: if an exception is thrown, there are no changes in the JSON va
 
 ## Complexity
 
-Proportional to the size of the JSON value `j` multiplied by its maximum nesting
-depth, `O(n × d)`. BSON length prefixes are computed recursively before nested
-values are written.
+Linear in the size of the JSON value `j`. The length prefixes of all nested documents and arrays are computed in one
+pass before anything is written.
 
 ## Examples
 
@@ -73,7 +72,9 @@ values are written.
 - [to_msgpack](to_msgpack.md) create a MessagePack serialization of a JSON value
 - [to_ubjson](to_ubjson.md) create a UBJSON serialization of a JSON value
 - [to_bjdata](to_bjdata.md) create a BJData serialization of a JSON value
+- [to_bon8](to_bon8.md) create a BON8 serialization of a JSON value
 
 ## Version history
 
 - Added in version 3.4.0.
+- Linear in the size of `j`, and no longer limited by the call stack for deeply nested values, since version 3.13.0.

docs/mkdocs/docs/api/basic_json/to_cbor.md

@@ -62,6 +62,7 @@ Linear in the size of the JSON value `j`.
 - [to_bson](to_bson.md) create a BSON serialization of a JSON value
 - [to_ubjson](to_ubjson.md) create a UBJSON serialization of a JSON value
 - [to_bjdata](to_bjdata.md) create a BJData serialization of a JSON value
+- [to_bon8](to_bon8.md) create a BON8 serialization of a JSON value
 
 ## Version history
 

docs/mkdocs/docs/api/basic_json/to_msgpack.md

@@ -34,6 +34,15 @@ The exact mapping and its limitations are described on a [dedicated page](../../
 
 Strong guarantee: if an exception is thrown, there are no changes in the JSON value.
 
+## Exceptions
+
+- Throws [`out_of_range.412`](../../home/exceptions.md#jsonexceptionout_of_range412) if the length of a string, binary
+  value, array, or object exceeds 4294967295, the maximum MessagePack can store; example:
+  `"MessagePack length 4294967296 exceeds maximum of 4294967295"`
+- Throws [`out_of_range.415`](../../home/exceptions.md#jsonexceptionout_of_range415) if the subtype of a binary value
+  exceeds 255, the maximum of the MessagePack ext type; example:
+  `"subtype 70000 is too large for the MessagePack ext type (max 255)"`
+
 ## Complexity
 
 Linear in the size of the JSON value `j`.
@@ -61,7 +70,9 @@ Linear in the size of the JSON value `j`.
 - [to_bson](to_bson.md) create a BSON serialization of a JSON value
 - [to_ubjson](to_ubjson.md) create a UBJSON serialization of a JSON value
 - [to_bjdata](to_bjdata.md) create a BJData serialization of a JSON value
+- [to_bon8](to_bon8.md) create a BON8 serialization of a JSON value
 
 ## Version history
 
 - Added in version 2.0.9.
+- Throws `out_of_range.412` and `out_of_range.415` since version 3.13.0.

docs/mkdocs/docs/api/basic_json/to_ubjson.md

@@ -77,6 +77,7 @@ Linear in the size of the JSON value `j`.
 - [to_msgpack](to_msgpack.md) create a MessagePack serialization of a JSON value
 - [to_bson](to_bson.md) create a BSON serialization of a JSON value
 - [to_bjdata](to_bjdata.md) create a BJData serialization of a JSON value
+- [to_bon8](to_bon8.md) create a BON8 serialization of a JSON value
 
 ## Version history
 

docs/mkdocs/docs/api/basic_json/unflatten.md

@@ -37,7 +37,14 @@ Linear in the size of the JSON value.
 ## Notes
 
 Empty objects and arrays are flattened by [`flatten()`](flatten.md) to `#!json null` values and cannot unflattened to
-their original type. Apart from this example, for a JSON value `j`, the following is always true:
+their original type.
+
+A flattened array and a flattened object whose keys are array indices are indistinguishable, because both are
+described by the same JSON pointers. A value is therefore restored as an array if and only if one of its keys is the
+reference token `0`, and as an object otherwise: `#!json {"2": 1}` is restored unchanged, whereas `#!json {"0": 1}` is
+restored as `#!json [1]`. This decision does not depend on the order in which the flattened object is iterated.
+
+Apart from these two cases, for a JSON value `j`, the following is always true:
 `#!cpp j == j.flatten().unflatten()`.
 
 ## Examples
@@ -63,3 +70,4 @@ their original type. Apart from this example, for a JSON value `j`, the followin
 ## Version history
 
 - Added in version 2.0.0.
+- Made the array/object decision independent of the object's iteration order in version 3.13.0.

docs/mkdocs/docs/api/macros/index.md

@@ -14,6 +14,13 @@ header. See also the [macro overview page](../../features/macros.md).
 - [**JSON_DIAGNOSTIC_POSITIONS**](json_diagnostic_positions.md) - access positions of elements
 - [**JSON_NOEXCEPTION**](json_noexception.md) - switch off exceptions
 
+## Parsing
+
+- [**JSON_PRECISE_STREAM_POSITION**](json_precise_stream_position.md) - opt in to leaving an input stream positioned
+  right after a parsed number
+- [**JSON_STRICT_NUL_HANDLING**](json_strict_nul_handling.md) - opt in to rejecting a NUL byte in the input instead of
+  treating it as end of input
+
 ## Language support
 
 - [**JSON_HAS_CPP_11**<br>**JSON_HAS_CPP_14**<br>**JSON_HAS_CPP_17**<br>**JSON_HAS_CPP_20**](json_has_cpp_11.md) - set supported C++ standard
@@ -22,6 +29,7 @@ header. See also the [macro overview page](../../features/macros.md).
 - [**JSON_HAS_STD_FORMAT**](json_has_std_format.md) - control `std::format`/`std::formatter` support
 - [**JSON_HAS_THREE_WAY_COMPARISON**](json_has_three_way_comparison.md) - control 3-way comparison support
 - [**JSON_NO_IO**](json_no_io.md) - switch off functions relying on certain C++ I/O headers
+- [**JSON_NO_THREAD_LOCAL**](json_no_thread_local.md) - switch off the use of `thread_local` storage
 - [**JSON_SKIP_UNSUPPORTED_COMPILER_CHECK**](json_skip_unsupported_compiler_check.md) - do not warn about unsupported compilers
 - [**JSON_USE_GLOBAL_UDLS**](json_use_global_udls.md) - place user-defined string literals (UDLs) into the global namespace
 - [**JSON_USE_SIMDUTF**](json_use_simdutf.md) - use the simdutf library to accelerate UTF-8 validation

docs/mkdocs/docs/api/macros/json_brace_init_copy_semantics.md

@@ -38,6 +38,28 @@ The default value is `0` (disabled — existing behavior is preserved).
 
     This macro must be defined **before** including `<nlohmann/json.hpp>`. Defining it after the include has no effect.
 
+!!! warning "Applies to every single-element list"
+
+    The macro does not only affect a single JSON value in braces. **Any** single-element braced list is treated as its
+    element, so it no longer creates a one-element array:
+
+    ```cpp
+    json j1 = {1};       // 1, not [1]
+    json j2 = {"text"};  // "text", not ["text"]
+    json j3 = {{1, 2}};  // [1,2], not [[1,2]]
+    ```
+
+    Code that relies on these producing arrays must use `json::array()` instead (see below). Lists with more than one
+    element, and a single `[string, value]` pair such as `{{"key", "value"}}`, which still creates an object, are not
+    affected. The library's own conversions are not affected either: for example, `std::tuple<int>{5}` still becomes
+    `[5]`.
+
+!!! note "ABI compatibility"
+
+    The value of this macro is encoded in the [namespace](../../features/namespace.md) (tag `_bics`), resulting in
+    distinct symbol names. Translation units compiled with and without it can therefore be linked into the same program
+    without One Definition Rule (ODR) violations, but they cannot exchange instances of library types.
+
 !!! tip "Workaround without the macro"
 
     To explicitly create a single-element array without enabling this macro, use `json::array()`:

docs/mkdocs/docs/api/macros/json_no_thread_local.md

@@ -0,0 +1,48 @@
+# JSON_NO_THREAD_LOCAL
+
+```cpp
+#define JSON_NO_THREAD_LOCAL
+```
+
+When defined, the library does not use `#!cpp thread_local` storage. This is relevant for the few environments whose
+toolchain does not support it.
+
+Copying a value and comparing two values both descend into the first levels by letting the containers copy or compare
+themselves, and finish whatever is nested deeper than that without the call stack, so that neither can exhaust the stack
+however deeply the values are nested. Each counts the levels it has descended into in a `#!cpp thread_local` variable, as
+a counter shared between threads would be raced.
+
+Without those counters, no descent can be bounded safely, so objects and arrays are copied and compared without the call
+stack right away. Both keep working exactly as they do otherwise - the same values come out, the same comparisons hold,
+and deeply nested values are handled just as safely - but both are slower, because the containers no longer copy or
+compare themselves. Copying the benchmark documents takes 9% (`canada.json`) to 34% (`twitter.json`) longer, and
+comparing two equal ones 10% (`citm_catalog.json`) to 90% (`canada.json`) longer.
+
+## Default definition
+
+By default, `#!cpp JSON_NO_THREAD_LOCAL` is not defined.
+
+```cpp
+#undef JSON_NO_THREAD_LOCAL
+```
+
+The library defines it by itself for Clang targeting MinGW, which does not survive the `#!cpp thread_local` storage:
+copying a value segfaults there, with both old and current Clang versions, while GCC targeting MinGW is unaffected.
+Copying and comparing fall back to working without the call stack there, as they do whenever the macro is defined.
+
+## Examples
+
+??? example
+
+    The code below forces the library not to use `#!cpp thread_local` storage.
+
+    ```cpp
+    #define JSON_NO_THREAD_LOCAL 1
+    #include <nlohmann/json.hpp>
+
+    ...
+    ```
+
+## Version history
+
+- Added in version 3.12.1.

docs/mkdocs/docs/api/macros/json_precise_stream_position.md

@@ -0,0 +1,131 @@
+# JSON_PRECISE_STREAM_POSITION
+
+```cpp
+#define JSON_PRECISE_STREAM_POSITION /* value */
+```
+
+When defined to `1`, [`operator>>`](../operator_gtgt.md) and [`sax_parse`](../basic_json/sax_parse.md) with
+`strict = false` leave a `#!cpp std::istream` positioned right after the parsed value for every value type. By default,
+the character that terminates a number is consumed as well.
+
+The macro only affects reading from a `#!cpp std::istream` when the rest of the stream is not required to be consumed.
+[`parse`](../basic_json/parse.md), [`accept`](../basic_json/accept.md), and all other inputs (strings, iterators,
+containers, `#!cpp FILE*`) are never affected.
+
+## Default definition
+
+The default value is `0` (disabled — existing behavior is preserved).
+
+```cpp
+#define JSON_PRECISE_STREAM_POSITION 0
+```
+
+## Notes
+
+!!! note "Background"
+
+    A number is the only JSON value whose end can be detected solely by reading the character that follows it. By
+    default, that character is consumed and not put back, so the stream is left one byte too far after a number, and
+    only after a number:
+
+    ```cpp
+    std::istringstream input("1true");
+    json j;
+    input >> j;  // j == 1, but the stream now starts at "rue"
+    ```
+
+    With this macro, the character is only looked at and left in the stream, so the stream starts at `true`. This
+    does not require the stream buffer to support putting a character back.
+
+    This was not changed unconditionally, because code can depend on the consumed character, even unknowingly (see
+    [#5340](https://github.com/nlohmann/json/issues/5340)). Both of the following work by default only because the
+    character after each number is swallowed, and behave differently with this macro:
+
+    ```cpp
+    std::istringstream input("1,2,3");
+    json j1, j2, j3;
+    input >> j1 >> j2 >> j3;  // default: 1, 2, 3
+                              // with the macro: throws parse_error.101 at the ','
+    ```
+
+    ```cpp
+    std::istringstream input("42\nfoo");
+    json j;
+    std::string line;
+    input >> j;
+    std::getline(input, line);  // default: "foo"
+                                // with the macro: "" (like after reading an int with >>)
+    ```
+
+    In both cases, the behavior with the macro is what you already get today when the value is not a number: `"a","b"`
+    fails at the `,`, and `std::getline` after `{}` returns an empty string. This macro offers an opt-in path to
+    the consistent behavior ahead of version 4.0.0, where it is planned to become the default.
+
+!!! warning "Opt-in only"
+
+    This macro must be defined **before** including `<nlohmann/json.hpp>`. Defining it after the include has no
+    effect.
+
+!!! note "ABI compatibility"
+
+    The value of this macro is encoded in the [namespace](../../features/namespace.md) (tag `_psp`), resulting in
+    distinct symbol names. Translation units compiled with and without it can therefore be linked into the same program
+    without One Definition Rule (ODR) violations, but they cannot exchange instances of library types.
+
+!!! tip "Workaround without the macro"
+
+    Separate the values in the stream with whitespace. The character consumed after a number is then the separator,
+    and whitespace before the next value is skipped anyway.
+
+## Examples
+
+??? example "Default behavior (macro not defined)"
+
+    Without the macro, the character after a number is consumed:
+
+    ```cpp
+    #include <iostream>
+    #include <sstream>
+    #include <nlohmann/json.hpp>
+
+    using json = nlohmann::json;
+
+    int main()
+    {
+        std::istringstream input("1true");
+        json j1, j2;
+        input >> j1;  // j1 == 1
+        input >> j2;  // throws parse_error.101: the stream now starts at "rue"
+    }
+    ```
+
+??? example "Opt-in precise stream position (macro defined to 1)"
+
+    With the macro, the stream is positioned right after the number:
+
+    ```cpp
+    #define JSON_PRECISE_STREAM_POSITION 1
+    #include <iostream>
+    #include <sstream>
+    #include <nlohmann/json.hpp>
+
+    using json = nlohmann::json;
+
+    int main()
+    {
+        std::istringstream input("1true");
+        json j1, j2;
+        input >> j1;  // j1 == 1
+        input >> j2;  // j2 == true
+    }
+    ```
+
+## See also
+
+- [**operator>>**](../operator_gtgt.md) - deserialize from stream
+- [**sax_parse**](../basic_json/sax_parse.md) - generate SAX events
+
+## Version history
+
+- Added in version 3.13.0.
+- Planned to become the default (with the macro removed) in version 4.0.0.

docs/mkdocs/docs/api/macros/json_strict_nul_handling.md

@@ -0,0 +1,132 @@
+# JSON_STRICT_NUL_HANDLING
+
+```cpp
+#define JSON_STRICT_NUL_HANDLING /* value */
+```
+
+When defined to `1`, a `'\0'` (NUL) byte in JSON text input is rejected with `parse_error.101`, like any other
+unexpected byte, instead of being silently treated as end of input.
+
+The macro only affects the JSON text parser ([`parse`](../basic_json/parse.md), [`accept`](../basic_json/accept.md),
+[`sax_parse`](../basic_json/sax_parse.md), and [`operator>>`](../operator_gtgt.md)). There are three cases where a NUL
+byte is still not rejected:
+
+- The binary formats ([`from_bjdata`](../basic_json/from_bjdata.md), [`from_bon8`](../basic_json/from_bon8.md),
+  [`from_bson`](../basic_json/from_bson.md), [`from_cbor`](../basic_json/from_cbor.md),
+  [`from_msgpack`](../basic_json/from_msgpack.md), [`from_ubjson`](../basic_json/from_ubjson.md)) are never affected: there, `0x00` is ordinary data.
+- A bare `const char*` pointer has no length of its own, so its length is still determined with `strlen()`. The first
+  NUL byte therefore still marks the end of the input, and nothing after it is read.
+- One trailing `'\0'` at the end of a `char` array (e.g., a string literal) is trimmed; see the warning below.
+
+## Default definition
+
+The default value is `0` (disabled — existing behavior is preserved).
+
+```cpp
+#define JSON_STRICT_NUL_HANDLING 0
+```
+
+## Notes
+
+!!! note "Background"
+
+    By default, a `'\0'` byte anywhere in the input is treated the same as the real end of the input, rather than as
+    an ordinary (and, outside of a string, invalid) byte. Everything from that byte onward is silently ignored,
+    without a parse error - including further, otherwise well-formed JSON:
+
+    ```cpp
+    json::parse(std::string("123") + '\0');          // == 123, no error
+    json::parse(std::string("123") + '\0' + "true"); // == 123, the "true" is silently ignored too
+    ```
+
+    This falls out of the same convention used when no explicit input length is given at all: parsing from a
+    `const char*` already stops at the first NUL byte via `strlen()`, since a bare pointer has no length of its own.
+    The library applies that same NUL-terminated-C-string convention uniformly, rather than only when a length is
+    genuinely unavailable - so a `std::string`, iterator range, or container whose content happens to include a NUL
+    byte is affected the same way a raw `const char*` would be (see the
+    [FAQ entry](../../home/faq.md#nul-bytes-in-the-input) for a fuller explanation).
+
+    This was not fixed unconditionally, because doing so is backwards-incompatible for any caller who happens to
+    depend on the current behavior - even unknowingly, for instance because their input already contains trailing
+    padding they never noticed was being discarded (see [#5530](https://github.com/nlohmann/json/issues/5530)).
+    This macro instead offers an opt-in path to the corrected behavior ahead of version 4.0.0, where it is planned to
+    become the default.
+
+!!! warning "Opt-in only"
+
+    This macro must be defined **before** including `<nlohmann/json.hpp>`. Defining it after the include has no
+    effect.
+
+    Enabling it also changes how a `char` array (including a string literal, e.g. `json::parse("123")`) is read: such
+    an array normally carries a trailing `'\0'` contributed by the compiler, not by the source text. With this macro
+    enabled, that one trailing byte is trimmed if present so that parsing a string literal keeps working; every other
+    byte in the array - including any `'\0'` that is not the very last element - is read as real data and rejected
+    like any other unexpected byte. Arrays of any other element type (`unsigned char`, `std::uint8_t`, ...), as used
+    for CBOR or MessagePack, are never affected by this trimming; their full extent - including a genuine trailing
+    `0x00` - is always preserved, in both states of this macro.
+
+!!! note "ABI compatibility"
+
+    The value of this macro is encoded in the [namespace](../../features/namespace.md) (tag `_snul`), resulting in
+    distinct symbol names. Translation units compiled with and without it can therefore be linked into the same program
+    without One Definition Rule (ODR) violations, but they cannot exchange instances of library types.
+
+!!! tip "Workaround without the macro"
+
+    To reject a NUL byte without enabling this macro, trim your input yourself before calling `parse()`:
+
+    ```cpp
+    s.resize(s.find('\0')); // drop everything from the first NUL onward, if any
+    json::parse(s);
+    ```
+
+## Examples
+
+??? example "Default behavior (macro not defined)"
+
+    Without the macro, a NUL byte silently ends parsing at that point:
+
+    ```cpp
+    #include <nlohmann/json.hpp>
+
+    using json = nlohmann::json;
+
+    int main()
+    {
+        json j = json::parse(std::string("123") + '\0' + "true");
+        // j is 123 -- the '\0' and everything after it is silently ignored
+    }
+    ```
+
+??? example "Opt-in strict handling (macro defined to 1)"
+
+    With the macro, a NUL byte is rejected like any other unexpected byte:
+
+    ```cpp
+    #define JSON_STRICT_NUL_HANDLING 1
+    #include <nlohmann/json.hpp>
+
+    using json = nlohmann::json;
+
+    int main()
+    {
+        json j = json::parse(std::string("123") + '\0' + "true");
+        // throws parse_error.101 -- the NUL byte is now invalid input,
+        // exactly like any other unexpected trailing byte
+
+        json ok = json::parse("123");
+        // ok is 123 -- parsing from a string literal still works
+    }
+    ```
+
+## See also
+
+- [FAQ: NUL bytes in the input](../../home/faq.md#nul-bytes-in-the-input)
+- [**parse**](../basic_json/parse.md) - deserialize from a compatible input
+- [**accept**](../basic_json/accept.md) - check if the input is valid JSON
+- [**operator>>**](../operator_gtgt.md) - deserialize from stream
+
+## Version history
+
+- Added in version 3.13.0.
+- Planned to become the default (with the macro removed) in version 4.0.0.

docs/mkdocs/docs/api/macros/json_throw_user.md

@@ -12,9 +12,11 @@
 Controls how exceptions are handled by the library.
 
 1. This macro overrides [`#!cpp catch`](https://en.cppreference.com/w/cpp/language/try_catch) calls inside the library.
-   The argument is the type of the exception to catch. As of version 3.8.0, the library only catches `std::out_of_range`
-   exceptions internally to rethrow them as [`json::out_of_range`](../../home/exceptions.md#out-of-range) exceptions.
-   The macro is always followed by a scope.
+   The argument is the type of the exception to catch. The library uses it in a single place: to swallow any exception
+   escaping the parent-pointer check that [`JSON_DIAGNOSTICS`](json_diagnostics.md) adds to the class invariant. The
+   places where the library catches its own [`json::out_of_range`](../../home/exceptions.md#out-of-range) exceptions
+   use `JSON_INTERNAL_CATCH` instead, which `JSON_CATCH_USER` also overrides unless `JSON_INTERNAL_CATCH_USER` is
+   defined. The macro is always followed by a scope.
 2. This macro overrides `#!cpp throw` calls inside the library. The argument is the exception to be thrown. Note that
    `JSON_THROW_USER` should leave the current scope (e.g., by throwing or aborting), as continuing after it may yield
    undefined behavior.

docs/mkdocs/docs/api/macros/json_use_implicit_conversions.md

@@ -24,6 +24,14 @@ By default, implicit conversions are enabled.
     You can prepare existing code by already defining `JSON_USE_IMPLICIT_CONVERSIONS` to `0` and replace any implicit
     conversions with calls to [`get`](../basic_json/get.md).
 
+!!! tip "Automatic migration"
+
+    The community-maintained clang-tidy check `modernize-nlohmann-json-explicit-conversions` rewrites implicit
+    conversions into explicit calls to [`get`](../basic_json/get.md); for example, `#!cpp int i = j;` becomes
+    `#!cpp int i = j.get<int>();`. The check is not part of clang-tidy itself, and it does not catch every case (for
+    example, constructing a `std::optional` from a JSON value), so review the result. See
+    [discussion #4610](https://github.com/nlohmann/json/discussions/4610) for how to build and use it.
+
 !!! hint "CMake option"
 
     Implicit conversions can also be controlled with the CMake option

docs/mkdocs/docs/api/macros/nlohmann_define_derived_type.md

@@ -57,7 +57,8 @@ Summary:
 :   name of the base type (class, struct) `type` is derived from
 
 `member` (in)
-:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
+:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated
+    list, which may also be empty
 
 ## Default definition
 
@@ -127,6 +128,20 @@ void to_json(BasicJsonType& j, const B& b) {
     - Macros 4, 5, and 6 have the same prerequisites of [NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE](nlohmann_define_type_non_intrusive.md).
     - Serialization/deserialization of base types must be defined.
 
+!!! info "Derived types without own members"
+
+    The member list may be empty. The macro then generates a `to_json`/`from_json` pair that only delegates to
+    the base type, so `type` serializes exactly like `base_type`:
+
+    ```cpp
+    struct derived : base
+    {
+        NLOHMANN_DEFINE_DERIVED_TYPE_INTRUSIVE(derived, base)
+    };
+    ```
+
+    The `WITH_NAMES` variants do not support this.
+
 !!! warning "Implementation limits"
 
     See Implementation limits for [NLOHMANN_DEFINE_TYPE_INTRUSIVE](nlohmann_define_type_intrusive.md) and

docs/mkdocs/docs/api/macros/nlohmann_define_type_intrusive.md

@@ -33,7 +33,8 @@ Summary:
 :   name of the type (class, struct) to serialize/deserialize
 
 `member` (in)
-:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
+:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated
+    list, which may also be empty
 
 ## Default definition
 
@@ -58,6 +59,20 @@ See the examples below for the concrete generated code.
 
 [GetNonDefNonCopy]: ../../features/arbitrary_types.md#how-can-i-use-get-for-non-default-constructiblenon-copyable-types
 
+!!! info "Types without members"
+
+    The member list may be empty. The macro then generates a `to_json` that produces an empty JSON object
+    `#!json {}`, and a `from_json` that reads no members:
+
+    ```cpp
+    struct marker
+    {
+        NLOHMANN_DEFINE_TYPE_INTRUSIVE(marker)
+    };
+    ```
+
+    The `WITH_NAMES` variants do not support this.
+
 !!! warning "Implementation limits"
 
     - The current implementation is limited to at most 63 member variables. If you want to serialize/deserialize types

docs/mkdocs/docs/api/macros/nlohmann_define_type_non_intrusive.md

@@ -33,7 +33,8 @@ Summary:
 :   name of the type (class, struct) to serialize/deserialize
 
 `member` (in)
-:   name of the (public) member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
+:   name of the (public) member variable to serialize/deserialize; up to 63 members can be given as a
+    comma-separated list, which may also be empty
 
 ## Default definition
 
@@ -59,6 +60,18 @@ See the examples below for the concrete generated code.
 
 [GetNonDefNonCopy]: ../../features/arbitrary_types.md#how-can-i-use-get-for-non-default-constructiblenon-copyable-types
 
+!!! info "Types without members"
+
+    The member list may be empty. The macro then generates a `to_json` that produces an empty JSON object
+    `#!json {}`, and a `from_json` that reads no members:
+
+    ```cpp
+    struct marker {};
+    NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(marker)
+    ```
+
+    The `WITH_NAMES` variants do not support this.
+
 !!! warning "Implementation limits"
 
     - The current implementation is limited to at most 63 member variables. If you want to serialize/deserialize types

docs/mkdocs/docs/api/operator_gtgt.md

@@ -67,11 +67,20 @@ input >> j2;  // parses the next value
     Only numbers are affected. Values ending in a self-delimiting character do not read past themselves, so
     `truefalse`, `[1][2]`, `{"a":1}{"b":2}`, and `"a""b"` can be read back to back without a separator.
 
-    This is tracked in [#5340](https://github.com/nlohmann/json/issues/5340).
+    Define [`JSON_PRECISE_STREAM_POSITION`](macros/json_precise_stream_position.md) to `1` to leave the terminating character in the stream
+    instead, so that the stream is positioned right after the value for every value type and no separator is
+    needed. This is tracked in [#5340](https://github.com/nlohmann/json/issues/5340).
 
 Note that reading concatenated values does **not** work for [JSON Lines](../features/parsing/json_lines.md)
 (newline-delimited JSON) input -- see that page for why and for the recommended alternative.
 
+By default, a `'\0'` (NUL) byte encountered while reading a value is treated as end of input, rather than as an
+ordinary (and, outside of a string, invalid) byte; see the [FAQ entry](../home/faq.md#nul-bytes-in-the-input) for
+details and the [`JSON_STRICT_NUL_HANDLING`](macros/json_strict_nul_handling.md) macro to opt into rejecting it
+instead. Because `operator>>` only parses a single value and does not require the rest of the stream to be consumed,
+a NUL byte *after* a complete value has no effect on `operator>>` either way; it only matters while a value is still
+being read.
+
 !!! warning "Deprecation"
 
     This function replaces function `#!cpp std::istream& operator<<(basic_json& j, std::istream& i)` which has
@@ -98,7 +107,14 @@ Note that reading concatenated values does **not** work for [JSON Lines](../feat
 
 - [accept](basic_json/accept.md) - check if the input is valid JSON
 - [parse](basic_json/parse.md) - deserialize from a compatible input
+- [`JSON_STRICT_NUL_HANDLING`](macros/json_strict_nul_handling.md) - opt in to rejecting a NUL byte in the input
+  instead of treating it as end of input
+- [`JSON_PRECISE_STREAM_POSITION`](macros/json_precise_stream_position.md) - opt in to leaving the stream positioned right after a number
 
 ## Version history
 
 - Added in version 1.0.0.
+- `JSON_STRICT_NUL_HANDLING` added in version 3.13.0 to optionally reject a NUL byte in the input instead of treating
+  it as end of input; planned to become the default in version 4.0.0.
+- `JSON_PRECISE_STREAM_POSITION` added in version 3.13.0 to optionally leave the character that terminates a number in
+  the stream; planned to become the default in version 4.0.0.

docs/mkdocs/docs/api/ordered_json.md

@@ -15,9 +15,9 @@ reference after the insertion point will point to the same index, which is now a
 
 ## Complexity
 
-[`ordered_map`](ordered_map.md) has no lookup index: every key-based object operation is a linear scan, so building or
+[`ordered_map`](ordered_map/index.md) has no lookup index: every key-based object operation is a linear scan, so building or
 parsing an object of `n` keys costs O(n²) rather than O(n log n). See
-[`ordered_map` complexity](ordered_map.md#complexity) for the per-operation table and for measured numbers.
+[`ordered_map` complexity](ordered_map/index.md#complexity) for the per-operation table and for measured numbers.
 
 ## Examples
 

docs/mkdocs/docs/community/assurance_case.md

@@ -0,0 +1,70 @@
+# Assurance case
+
+This page argues why the library meets its security requirements. It describes the threats the library faces, where the
+trust boundaries lie, and how the library's design and the [quality assurance](quality_assurance.md) counter these
+threats. To report a vulnerability, see the [security policy](security_policy.md).
+
+## Threat model
+
+The library parses, stores, and serializes JSON values in memory. It does not open network connections, does not open
+files (it only reads from streams or `std::FILE*` handles that the caller has already opened), does not read environment
+variables, and does not implement cryptography or handle credentials.
+
+The primary threat is therefore **untrusted input**: JSON text or binary data (BJData, BSON, CBOR, MessagePack, UBJSON)
+that an attacker controls, passed to [`parse`](../api/basic_json/parse.md), [`accept`](../api/basic_json/accept.md),
+[`sax_parse`](../api/basic_json/sax_parse.md), or one of the `from_*` functions such as
+[`from_cbor`](../api/basic_json/from_cbor.md). Such input may try to
+
+- make the library read or write out of bounds (malformed lengths, truncated input, invalid UTF-8),
+- trigger undefined behavior (integer overflow in sizes or numbers, invalid casts),
+- exhaust memory (huge announced sizes), or
+- exhaust the call stack (deeply nested arrays and objects).
+
+## Trust boundaries
+
+- **Untrusted:** all serialized input read by the parser, the SAX interface, and the binary readers. The library must
+  handle every possible input by either producing a value or throwing a [`parse_error`](../home/exceptions.md#parse-errors)
+  (or returning `false` when exceptions are disabled for the call).
+- **Trusted:** the C++ code that calls the library. Calling a function with violated preconditions, for instance
+  accessing an array with [`operator[]`](../api/basic_json/operator%5B%5D.md) out of range, is a programming error and
+  not a security boundary. Such preconditions are checked with [runtime assertions](../features/assertions.md) in debug
+  builds; functions such as [`at`](../api/basic_json/at.md) offer checked access with exceptions.
+
+## Secure design
+
+- **Strict parsing.** The parser accepts exactly the JSON grammar of [RFC 8259](https://datatracker.ietf.org/doc/html/rfc8259).
+  Extensions such as [comments](../features/comments.md) and [trailing commas](../features/trailing_commas.md) must be
+  enabled explicitly. Invalid UTF-8 is rejected.
+- **Errors are reported, not ignored.** Malformed input results in a [`parse_error`](../home/exceptions.md#parse-errors)
+  with the byte position of the error. Binary readers do not trust announced sizes: strings and binary values grow
+  only as bytes are actually read, arrays reserve at most a fixed number of elements up front, and sizes that no
+  container can hold are rejected.
+- **Memory is owned by values.** Each `basic_json` value owns its content, and there is no manual memory management in
+  user code. The destructor does not recurse, so destroying a deeply nested value does not exhaust the stack.
+- **Bounded recursion.** The JSON parser and the binary readers keep their state in explicit stacks instead of
+  recursing per nesting level. Operations that walk a value, such as [`dump`](../api/basic_json/dump.md), copying,
+  comparison, hashing, and [`merge_patch`](../api/basic_json/merge_patch.md), recurse only up to a fixed depth and
+  continue with an explicit stack below it. Some operations, such as [`diff`](../api/basic_json/diff.md),
+  [`flatten`](../api/basic_json/flatten.md), and the binary writers, still recurse once per nesting level; work on them
+  is in progress. Applications that process untrusted input can limit its nesting depth with a
+  [parser callback](../features/parsing/parser_callbacks.md).
+- **Invariants are checked.** The class invariant (for instance, that the pointer for the stored type is never null) is
+  checked with runtime assertions throughout the test suite.
+
+## Common weaknesses
+
+The following table maps the relevant classes of the [Common Weakness Enumeration](https://cwe.mitre.org) to the
+measures that counter them. The measures are described in detail in [Quality assurance](quality_assurance.md).
+
+| Weakness                                                                  | Countermeasures                                                                                  |
+|---------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------|
+| Out-of-bounds read/write ([CWE-125](https://cwe.mitre.org/data/definitions/125.html), [CWE-787](https://cwe.mitre.org/data/definitions/787.html)) | bounds checks on all reads from the input; AddressSanitizer and Valgrind on the test suite; OSS-Fuzz      |
+| Integer overflow ([CWE-190](https://cwe.mitre.org/data/definitions/190.html)) | UndefinedBehaviorSanitizer with integer overflow detection; Clang-Tidy; Cppcheck                 |
+| Use after free, double free ([CWE-416](https://cwe.mitre.org/data/definitions/416.html), [CWE-415](https://cwe.mitre.org/data/definitions/415.html)) | ownership of all memory by values; AddressSanitizer and Valgrind; Clang Static Analyzer          |
+| Memory leaks ([CWE-401](https://cwe.mitre.org/data/definitions/401.html)) | Valgrind (Memcheck) on the test suite                                                            |
+| Uncontrolled recursion ([CWE-674](https://cwe.mitre.org/data/definitions/674.html)) | iterative parser, binary readers, and destructor; bounded recursion in value operations; tests with deeply nested inputs |
+| Uncontrolled resource consumption ([CWE-400](https://cwe.mitre.org/data/definitions/400.html)) | allocations based on announced sizes are capped; OSS-Fuzz with memory limits                     |
+| Undefined behavior in general ([CWE-758](https://cwe.mitre.org/data/definitions/758.html)) | UndefinedBehaviorSanitizer; runtime assertions; Clang-Tidy, Cppcheck, Clang Static Analyzer, Infer |
+
+In addition, every line of the library is covered by the unit tests, and all parsers are fuzz-tested around the clock
+by [OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json).

docs/mkdocs/docs/community/governance.md

@@ -91,6 +91,31 @@ activities include (but are not limited to):
 Users who continue to engage with the project and its community will often find themselves becoming more and more
 involved. Such users may then go on to become contributors, as described above.
 
+## Access to project resources
+
+The project's resources are the [GitHub repository](https://github.com/nlohmann/json) with its settings, CI workflows
+and secrets, and the documentation at [json.nlohmann.me](https://json.nlohmann.me), which is built and deployed from
+the repository. Currently, the project lead is the only person with write or admin access to them.
+
+### Granting access
+
+Write or admin access is only granted by the project lead, and only to a contributor whose track record in the project
+the project lead has reviewed first. The role is assigned manually and is the lowest one that is needed for the task.
+Access is removed when it is no longer needed. GitHub requires two-factor authentication for everyone who can modify the
+repository.
+
+### Secrets
+
+The CI workflows mostly use the token that GitHub creates for each workflow run. It is read-only by default, and each
+workflow requests only the additional permissions it needs. The few other credentials, such as the token for
+[Semgrep](https://semgrep.dev), are stored as encrypted GitHub Actions secrets:
+
+- Only people with admin access can create, change, or delete them. Their values cannot be read back, not even by
+  admins.
+- They are not passed to workflows that run for pull requests from forks.
+- They must never be committed to the repository or printed in logs.
+- They are rotated whenever someone with admin access leaves the project, and immediately if a leak is suspected.
+
 ## Support
 
 All participants in the community are encouraged to provide support for new users within the project management

docs/mkdocs/docs/community/index.md

@@ -5,4 +5,6 @@
 - [Contribution Guidelines](contribution_guidelines.md) - guidelines how to contribute to this project
 - [Governance](governance.md) - the governance model of this project
 - [Quality Assurance](quality_assurance.md) - how the quality of this project is assured
+- [Roadmap](roadmap.md) - what the project will and will not do
 - [Security Policy](security_policy.md) - the security policy of the project
+- [Assurance Case](assurance_case.md) - why the library meets its security requirements

docs/mkdocs/docs/community/quality_assurance.md

@@ -164,6 +164,9 @@ Note: Some modern features (like C++20 ranges or filesystem support) may be disa
 - [x] The parser is tested against extensive correctness suites for JSON compliance.
 - [x] In addition, the library is continuously fuzz-tested at [OSS-Fuzz](https://google.github.io/oss-fuzz/) where the
   library is checked against billions of inputs.
+- [x] Every crash reported by OSS-Fuzz is fixed together with a unit test that reproduces it, and the fix references
+  the OSS-Fuzz issue. The round-trip checks of the fuzzer drivers are also part of the unit tests. See the
+  [fuzz testing documentation](https://github.com/nlohmann/json/blob/develop/tests/fuzzing.md#handling-oss-fuzz-reports).
 
 ## Static analysis
 
@@ -197,6 +200,25 @@ Note: Some modern features (like C++20 ranges or filesystem support) may be disa
 - [x] The test suite is executed with [Sanitizers](https://github.com/google/sanitizers) (address sanitizer, undefined
   behavior sanitizer, integer overflow detection, nullability violations).
 
+## Dependencies
+
+!!! success "Requirement: No vulnerable dependencies"
+
+    The library has no dependencies besides the C++ standard library. The tools used to build, test, and document it
+    are kept free of known vulnerabilities.
+
+- [x] GitHub Actions are pinned to a commit hash, and the Python packages used by the documentation and the tools are
+  pinned to exact versions.
+- [x] [Dependabot](https://docs.github.com/en/code-security/dependabot) checks these dependencies daily and proposes
+  updates as pull requests.
+- [x] Every pull request is checked with the
+  [dependency review action](https://github.com/actions/dependency-review-action). A pull request that adds a
+  dependency with a known vulnerability of any severity fails this check and is not merged.
+- [x] Vulnerability alerts for dependencies are fixed or dismissed with a documented reason before the next release.
+  No release is made while such an alert is open.
+- [x] Third-party code included in the repository for testing, such as [doctest](https://github.com/doctest/doctest),
+  is updated manually.
+
 ## Style check
 
 !!! success "Requirement: Common code style"

docs/mkdocs/docs/community/roadmap.md

@@ -0,0 +1,43 @@
+# Roadmap
+
+This page describes what the project intends to do, and what it does not intend to do, over the next year. Concrete
+work items are tracked in the [GitHub milestones](https://github.com/nlohmann/json/milestones) and the
+[issue tracker](https://github.com/nlohmann/json/issues).
+
+## What the project will do
+
+- **Keep the C++11 baseline.** The library will continue to compile with every
+  [supported C++11 compiler](https://github.com/nlohmann/json/blob/develop/README.md#supported-compilers). Features of
+  later standards are only used when they are guarded by the `JSON_HAS_CPP_*` macros.
+- **Stay conformant to JSON.** The parser and serializer follow [RFC 8259](https://datatracker.ietf.org/doc/html/rfc8259).
+  Extensions such as [comments](../features/comments.md) or [trailing commas](../features/trailing_commas.md) remain
+  opt-in.
+- **Keep the 3.x public API stable.** Releases follow [semantic versioning](https://semver.org). Changes that would
+  break existing code are only added behind a feature macro, so users can opt in and test their code before a next
+  major release.
+- **Support a broad range of compilers and platforms.** The [CI](quality_assurance.md) keeps testing old and new
+  versions of GCC, Clang, MSVC, and other compilers on Linux, macOS, and Windows.
+- **Keep the quality assurance up.** Every change keeps the test coverage at 100%, passes the static and dynamic
+  analysis, and is fuzz-tested by OSS-Fuzz, see [Quality assurance](quality_assurance.md).
+- **Harden the library against hostile input.** Handling deeply nested values without exhausting the call stack is
+  ongoing work.
+- **Fix bugs and security issues** reported through the issue tracker and the [security policy](security_policy.md).
+
+## What the project will not do
+
+- **Break the public API of version 3.x.** See the
+  [contribution guidelines](https://github.com/nlohmann/json/blob/develop/.github/CONTRIBUTING.md#break-the-public-api)
+  for what counts as a breaking change.
+- **Require a newer C++ standard than C++11.**
+- **Break JSON conformance** or enable non-standard extensions by default.
+- **Add dependencies** or require a build step. The library remains header-only, and the single header
+  `json.hpp` remains a complete distribution.
+- **Trade simplicity for speed or memory efficiency.** Performance improvements are welcome, but the library is not
+  meant to compete with the fastest JSON libraries, see [Design goals](../home/design_goals.md).
+
+## Version 4.0
+
+There is no decision yet on whether or when a version 4.0 with breaking changes will be released. Proposals that need
+a major version, for instance stricter type conversions, are collected in issue
+[#3453](https://github.com/nlohmann/json/issues/3453). Until then, such changes are only added as opt-in behavior
+behind feature macros.

docs/mkdocs/docs/examples/custom_array_type.cpp

@@ -0,0 +1,19 @@
+#include <iostream>
+#include <map>
+
+#include <nlohmann/json.hpp>
+
+#include "custom_array_type.hpp"
+
+using custom_json = nlohmann::basic_json<std::map, custom_array_type>;
+
+int main()
+{
+    custom_json j = custom_json::array();
+    j.push_back(1);
+    j.push_back(2);
+    j.push_back(3);
+
+    std::cout << j.dump() << std::endl;
+    std::cout << std::boolalpha << (custom_json::parse(j.dump()) == j) << std::endl;
+}

docs/mkdocs/docs/examples/custom_array_type.hpp

@@ -0,0 +1,152 @@
+#pragma once
+
+#include <memory>
+#include <utility>
+#include <vector>
+
+// A minimal, self-contained ArrayType built around a private std::vector.
+// See https://json.nlohmann.me/features/types/template_parameters/#arraytype
+template<class T, class Allocator = std::allocator<T>>
+class custom_array_type
+{
+    using vector_t = std::vector<T, Allocator>;
+    vector_t data_;
+
+  public:
+    using value_type = typename vector_t::value_type;
+    using size_type = typename vector_t::size_type;
+    using iterator = typename vector_t::iterator;
+    using const_iterator = typename vector_t::const_iterator;
+
+    custom_array_type() = default;
+    custom_array_type(const custom_array_type&) = default;
+    custom_array_type(custom_array_type&&) = default;
+    custom_array_type& operator=(const custom_array_type&) = default;
+    custom_array_type& operator=(custom_array_type&&) = default;
+
+    template<class InputIt>
+    custom_array_type(InputIt first, InputIt last) : data_(first, last) {}
+
+    custom_array_type(size_type count, const T& value) : data_(count, value) {}
+
+    iterator begin()
+    {
+        return data_.begin();
+    }
+    iterator end()
+    {
+        return data_.end();
+    }
+    const_iterator begin() const
+    {
+        return data_.begin();
+    }
+    const_iterator end() const
+    {
+        return data_.end();
+    }
+    const_iterator cbegin() const
+    {
+        return data_.cbegin();
+    }
+    const_iterator cend() const
+    {
+        return data_.cend();
+    }
+
+    bool empty() const
+    {
+        return data_.empty();
+    }
+    size_type size() const
+    {
+        return data_.size();
+    }
+    size_type max_size() const
+    {
+        return data_.max_size();
+    }
+    void clear()
+    {
+        data_.clear();
+    }
+    void resize(size_type n)
+    {
+        data_.resize(n);
+    }
+
+    T& operator[](size_type pos)
+    {
+        return data_[pos];
+    }
+    const T& operator[](size_type pos) const
+    {
+        return data_[pos];
+    }
+
+    T& back()
+    {
+        return data_.back();
+    }
+    const T& back() const
+    {
+        return data_.back();
+    }
+
+    void push_back(const T& value)
+    {
+        data_.push_back(value);
+    }
+    void push_back(T&& value)
+    {
+        data_.push_back(std::move(value));
+    }
+
+    template<class... Args>
+    void emplace_back(Args&& ... args)
+    {
+        data_.emplace_back(std::forward<Args>(args)...);
+    }
+
+    void pop_back()
+    {
+        data_.pop_back();
+    }
+
+    iterator insert(const_iterator pos, const T& value)
+    {
+        return data_.insert(pos, value);
+    }
+    iterator insert(const_iterator pos, size_type count, const T& value)
+    {
+        return data_.insert(pos, count, value);
+    }
+    template<class InputIt>
+    iterator insert(const_iterator pos, InputIt first, InputIt last)
+    {
+        return data_.insert(pos, first, last);
+    }
+
+    iterator erase(const_iterator pos)
+    {
+        return data_.erase(pos);
+    }
+    iterator erase(const_iterator first, const_iterator last)
+    {
+        return data_.erase(first, last);
+    }
+
+    void swap(custom_array_type& other)
+    {
+        data_.swap(other.data_);
+    }
+
+    friend bool operator==(const custom_array_type& lhs, const custom_array_type& rhs)
+    {
+        return lhs.data_ == rhs.data_;
+    }
+    friend bool operator<(const custom_array_type& lhs, const custom_array_type& rhs)
+    {
+        return lhs.data_ < rhs.data_;
+    }
+};

docs/mkdocs/docs/examples/custom_array_type.output

@@ -0,0 +1,2 @@
+[1,2,3]
+true

docs/mkdocs/docs/examples/custom_binary_type.cpp

@@ -0,0 +1,21 @@
+#include <cstdint>
+#include <iostream>
+#include <map>
+#include <string>
+#include <vector>
+
+#include <nlohmann/json.hpp>
+
+#include "custom_binary_type.hpp"
+
+using custom_json = nlohmann::basic_json<std::map, std::vector, std::string, bool,
+      std::int64_t, std::uint64_t, double, std::allocator,
+      nlohmann::adl_serializer, custom_binary_type>;
+
+int main()
+{
+    const auto j = custom_json::binary({0x01, 0x02, 0x03});
+
+    std::cout << j.dump() << std::endl;
+    std::cout << std::boolalpha << (custom_json::from_cbor(custom_json::to_cbor(j)) == j) << std::endl;
+}

docs/mkdocs/docs/examples/custom_binary_type.hpp

@@ -0,0 +1,112 @@
+#pragma once
+
+#include <cstdint>
+#include <initializer_list>
+#include <vector>
+
+// A minimal, self-contained BinaryType built around a private std::vector.
+// See https://json.nlohmann.me/features/types/template_parameters/#binarytype
+class custom_binary_type
+{
+    using vector_t = std::vector<std::uint8_t>;
+    vector_t data_;
+
+  public:
+    using value_type = vector_t::value_type;
+    using size_type = vector_t::size_type;
+    using iterator = vector_t::iterator;
+    using const_iterator = vector_t::const_iterator;
+
+    custom_binary_type() = default;
+    custom_binary_type(const custom_binary_type&) = default;
+    custom_binary_type(custom_binary_type&&) = default;
+    custom_binary_type& operator=(const custom_binary_type&) = default;
+    custom_binary_type& operator=(custom_binary_type&&) = default;
+
+    template<class InputIt>
+    custom_binary_type(InputIt first, InputIt last) : data_(first, last) {}
+
+    // so basic_json::binary({0x01, 0x02}) can build one directly
+    custom_binary_type(std::initializer_list<std::uint8_t> init) : data_(init) {}
+
+    size_type size() const
+    {
+        return data_.size();
+    }
+    bool empty() const
+    {
+        return data_.empty();
+    }
+    void clear()
+    {
+        data_.clear();
+    }
+    void resize(size_type n)
+    {
+        data_.resize(n);
+    }
+
+    // read-only is enough: the writers only ever read from a binary value
+    const std::uint8_t* data() const
+    {
+        return data_.data();
+    }
+
+    std::uint8_t& operator[](size_type pos)
+    {
+        return data_[pos];
+    }
+    std::uint8_t operator[](size_type pos) const
+    {
+        return data_[pos];
+    }
+
+    std::uint8_t& back()
+    {
+        return data_.back();
+    }
+    std::uint8_t back() const
+    {
+        return data_.back();
+    }
+
+    iterator begin()
+    {
+        return data_.begin();
+    }
+    iterator end()
+    {
+        return data_.end();
+    }
+    const_iterator begin() const
+    {
+        return data_.begin();
+    }
+    const_iterator end() const
+    {
+        return data_.end();
+    }
+    const_iterator cbegin() const
+    {
+        return data_.cbegin();
+    }
+    const_iterator cend() const
+    {
+        return data_.cend();
+    }
+
+    template<class InputIt>
+    iterator insert(const_iterator pos, InputIt first, InputIt last)
+    {
+        return data_.insert(pos, first, last);
+    }
+
+    friend bool operator==(const custom_binary_type& lhs, const custom_binary_type& rhs)
+    {
+        return lhs.data_ == rhs.data_;
+    }
+    friend bool operator<(const custom_binary_type& lhs, const custom_binary_type& rhs)
+    {
+        return lhs.data_ < rhs.data_;
+    }
+};

docs/mkdocs/docs/examples/custom_binary_type.output

@@ -0,0 +1,2 @@
+{"bytes":[1,2,3],"subtype":null}
+true

docs/mkdocs/docs/examples/custom_object_type.cpp

@@ -0,0 +1,26 @@
+#include <iostream>
+#include <type_traits>
+#include <vector>
+
+#include <nlohmann/json.hpp>
+
+#include "custom_object_type.hpp"
+
+using custom_json = nlohmann::basic_json<custom_object_type, std::vector>;
+
+int main()
+{
+    custom_json j;
+    j["pi"] = 3.141;
+    j["happy"] = true;
+    j["list"] = {1, 2, 3};
+
+    std::cout << j.dump(2) << std::endl;
+    std::cout << std::boolalpha << (custom_json::parse(j.dump()) == j) << std::endl;
+
+    // custom_object_type has no key_compare member, so object_comparator_t
+    // falls back to its default
+    std::cout << std::boolalpha
+              << std::is_same<custom_json::object_comparator_t, custom_json::default_object_comparator_t>::value
+              << std::endl;
+}

docs/mkdocs/docs/examples/custom_object_type.hpp

@@ -0,0 +1,144 @@
+#pragma once
+
+#include <map>
+#include <utility>
+
+// A minimal, self-contained ObjectType built around a private std::map.
+// key_compare is deliberately not exposed: when an ObjectType has no
+// key_compare member, the library falls back to its own default comparator.
+// See https://json.nlohmann.me/features/types/template_parameters/#objecttype
+template<class Key, class T, class Compare, class Allocator>
+class custom_object_type
+{
+    using map_t = std::map<Key, T, Compare, Allocator>;
+    map_t data_;
+
+  public:
+    using key_type = typename map_t::key_type;
+    using mapped_type = typename map_t::mapped_type;
+    using value_type = typename map_t::value_type;
+    using size_type = typename map_t::size_type;
+    using iterator = typename map_t::iterator;
+    using const_iterator = typename map_t::const_iterator;
+
+    custom_object_type() = default;
+    custom_object_type(const custom_object_type&) = default;
+    custom_object_type(custom_object_type&&) = default;
+    custom_object_type& operator=(const custom_object_type&) = default;
+    custom_object_type& operator=(custom_object_type&&) = default;
+
+    template<class InputIt>
+    custom_object_type(InputIt first, InputIt last) : data_(first, last) {}
+
+    iterator begin()
+    {
+        return data_.begin();
+    }
+    iterator end()
+    {
+        return data_.end();
+    }
+    const_iterator begin() const
+    {
+        return data_.begin();
+    }
+    const_iterator end() const
+    {
+        return data_.end();
+    }
+    const_iterator cbegin() const
+    {
+        return data_.cbegin();
+    }
+    const_iterator cend() const
+    {
+        return data_.cend();
+    }
+
+    bool empty() const
+    {
+        return data_.empty();
+    }
+    size_type size() const
+    {
+        return data_.size();
+    }
+    size_type max_size() const
+    {
+        return data_.max_size();
+    }
+    void clear()
+    {
+        data_.clear();
+    }
+
+    iterator find(const key_type& key)
+    {
+        return data_.find(key);
+    }
+    const_iterator find(const key_type& key) const
+    {
+        return data_.find(key);
+    }
+    size_type count(const key_type& key) const
+    {
+        return data_.count(key);
+    }
+
+    std::pair<iterator, bool> emplace(const key_type& key, const mapped_type& value)
+    {
+        return data_.emplace(key, value);
+    }
+
+    std::pair<iterator, bool> insert(const value_type& value)
+    {
+        return data_.insert(value);
+    }
+
+    template<class InputIt>
+    void insert(InputIt first, InputIt last)
+    {
+        data_.insert(first, last);
+    }
+
+    mapped_type& operator[](const key_type& key)
+    {
+        return data_[key];
+    }
+
+    mapped_type& at(const key_type& key)
+    {
+        return data_.at(key);
+    }
+    const mapped_type& at(const key_type& key) const
+    {
+        return data_.at(key);
+    }
+
+    iterator erase(iterator pos)
+    {
+        return data_.erase(pos);
+    }
+    iterator erase(iterator first, iterator last)
+    {
+        return data_.erase(first, last);
+    }
+    size_type erase(const key_type& key)
+    {
+        return data_.erase(key);
+    }
+
+    void swap(custom_object_type& other)
+    {
+        data_.swap(other.data_);
+    }
+
+    friend bool operator==(const custom_object_type& lhs, const custom_object_type& rhs)
+    {
+        return lhs.data_ == rhs.data_;
+    }
+    friend bool operator<(const custom_object_type& lhs, const custom_object_type& rhs)
+    {
+        return lhs.data_ < rhs.data_;
+    }
+};

docs/mkdocs/docs/examples/custom_object_type.output

@@ -0,0 +1,11 @@
+{
+  "happy": true,
+  "list": [
+    1,
+    2,
+    3
+  ],
+  "pi": 3.141
+}
+true
+true

docs/mkdocs/docs/examples/custom_string_type.cpp

@@ -0,0 +1,20 @@
+#include <iostream>
+#include <map>
+#include <vector>
+
+#include <nlohmann/json.hpp>
+
+#include "custom_string_type.hpp"
+
+using custom_json = nlohmann::basic_json<std::map, std::vector, custom_string_type>;
+
+int main()
+{
+    custom_json j;
+    j["pi"] = 3.141;
+    j["happy"] = true;
+    j["list"] = {1, 2, 3};
+
+    std::cout << j.dump(2) << std::endl;
+    std::cout << std::boolalpha << (custom_json::parse(j.dump()) == j) << std::endl;
+}

docs/mkdocs/docs/examples/custom_string_type.hpp

@@ -0,0 +1,134 @@
+#pragma once
+
+#include <ostream>
+#include <string>
+
+// A minimal, self-contained StringType built around a private std::string.
+// Wraps rather than inherits, so it exposes exactly what the library needs
+// and nothing more of std::string's interface.
+//
+// Covers the "Always required" members, the extras needed for the binary
+// formats, and the extras needed for JSON Pointer / flatten / unflatten /
+// diff. Extending it further (e.g. for std::hash<basic_json> or to_bson) is
+// a matter of adding the extra members listed in the "Required for other
+// functionality" table.
+//
+// See https://json.nlohmann.me/features/types/template_parameters/#stringtype
+class custom_string_type
+{
+    std::string data_;
+
+  public:
+    using value_type = char;
+    using size_type = std::string::size_type;
+    using iterator = std::string::iterator;
+    using const_iterator = std::string::const_iterator;
+
+    static constexpr size_type npos = std::string::npos;
+
+    custom_string_type() = default;
+    custom_string_type(const custom_string_type&) = default;
+    custom_string_type(custom_string_type&&) = default;
+    custom_string_type& operator=(const custom_string_type&) = default;
+    custom_string_type& operator=(custom_string_type&&) = default;
+
+    // not explicit: the library relies on being able to hand it a string literal
+    custom_string_type(const char* s) : data_(s) {}
+    custom_string_type(const char* s, size_type count) : data_(s, count) {}
+    custom_string_type(size_type count, char ch) : data_(count, ch) {}
+
+    size_type size() const
+    {
+        return data_.size();
+    }
+    bool empty() const
+    {
+        return data_.empty();
+    }
+    void clear()
+    {
+        data_.clear();
+    }
+    void resize(size_type n)
+    {
+        data_.resize(n);
+    }
+    void resize(size_type n, char c)
+    {
+        data_.resize(n, c);
+    }
+    void reserve(size_type n)
+    {
+        data_.reserve(n);
+    }
+
+    // must stay null-terminated -- the parser hands this to std::strtoull &
+    // friends; std::string::data() has guaranteed that since C++11
+    const char* data() const
+    {
+        return data_.data();
+    }
+
+    void push_back(char c)
+    {
+        data_.push_back(c);
+    }
+
+    char& operator[](size_type pos)
+    {
+        return data_[pos];
+    }
+    char operator[](size_type pos) const
+    {
+        return data_[pos];
+    }
+
+    custom_string_type& append(const char* s, size_type count)
+    {
+        data_.append(s, count);
+        return *this;
+    }
+    custom_string_type& append(const custom_string_type& other)
+    {
+        data_.append(other.data_);
+        return *this;
+    }
+
+    size_type find_first_of(char c, size_type pos = 0) const
+    {
+        return data_.find_first_of(c, pos);
+    }
+
+    iterator begin()
+    {
+        return data_.begin();
+    }
+    iterator end()
+    {
+        return data_.end();
+    }
+    const_iterator begin() const
+    {
+        return data_.begin();
+    }
+    const_iterator end() const
+    {
+        return data_.end();
+    }
+
+    friend bool operator==(const custom_string_type& lhs, const custom_string_type& rhs)
+    {
+        return lhs.data_ == rhs.data_;
+    }
+    friend bool operator<(const custom_string_type& lhs, const custom_string_type& rhs)
+    {
+        return lhs.data_ < rhs.data_;
+    }
+
+    // not required by the library itself, but dump() returns a custom_string_type
+    // and this makes `std::cout << j.dump()` work as expected
+    friend std::ostream& operator<<(std::ostream& os, const custom_string_type& s)
+    {
+        return os << s.data_;
+    }
+};

docs/mkdocs/docs/examples/custom_string_type.output

@@ -0,0 +1,10 @@
+{
+  "happy": true,
+  "list": [
+    1,
+    2,
+    3
+  ],
+  "pi": 3.141
+}
+true

docs/mkdocs/docs/examples/from_bon8.cpp

@@ -0,0 +1,21 @@
+#include <iostream>
+#include <iomanip>
+#include <nlohmann/json.hpp>
+
+using json = nlohmann::json;
+
+int main()
+{
+    // create byte vector
+    std::vector<std::uint8_t> v = {0x89, 0x63, 0x6f, 0x6d, 0x70, 0x61, 0x63, 0x74,
+                                   0xf9, 0x66, 0x6f, 0x72, 0x6d, 0x61, 0x74, 0xff,
+                                   0x42, 0x4f, 0x4e, 0x38, 0xff, 0x73, 0x63, 0x68,
+                                   0x65, 0x6d, 0x61, 0x90
+                                  };
+
+    // deserialize it with BON8
+    json j = json::from_bon8(v);
+
+    // print the deserialized JSON value
+    std::cout << std::setw(2) << j << std::endl;
+}

docs/mkdocs/docs/examples/from_bon8.output

@@ -0,0 +1,5 @@
+{
+  "compact": true,
+  "format": "BON8",
+  "schema": 0
+}

docs/mkdocs/docs/examples/to_bon8.cpp

@@ -0,0 +1,22 @@
+#include <iostream>
+#include <iomanip>
+#include <nlohmann/json.hpp>
+
+using json = nlohmann::json;
+using namespace nlohmann::literals;
+
+int main()
+{
+    // create a JSON value
+    json j = R"({"compact": true, "format": "BON8", "schema": 0})"_json;
+
+    // serialize it to BON8
+    std::vector<std::uint8_t> v = json::to_bon8(j);
+
+    // print the vector content
+    for (auto& byte : v)
+    {
+        std::cout << "0x" << std::hex << std::setw(2) << std::setfill('0') << (int)byte << " ";
+    }
+    std::cout << std::endl;
+}

docs/mkdocs/docs/examples/to_bon8.output

@@ -0,0 +1 @@
+0x89 0x63 0x6f 0x6d 0x70 0x61 0x63 0x74 0xf9 0x66 0x6f 0x72 0x6d 0x61 0x74 0xff 0x42 0x4f 0x4e 0x38 0xff 0x73 0x63 0x68 0x65 0x6d 0x61 0x90 

docs/mkdocs/docs/features/arbitrary_types.md

@@ -215,6 +215,24 @@ For _derived_ classes and structs, use the following macros
     nlohmann::ordered_json j = p; // keys appear in declaration order: name, address, age
     ```
 
+!!! note "Zero-member types"
+
+    All 12 `NLOHMANN_DEFINE_TYPE_*`/`NLOHMANN_DEFINE_DERIVED_TYPE_*` macros (excluding the `WITH_NAMES` variants)
+    also accept types with no member variables to serialize, producing/accepting an empty JSON object `{}`
+    (or, for the derived-type macros, just the base class's own JSON representation):
+
+    ```cpp
+    namespace ns {
+        struct marker {
+            bool operator==(const marker&) const { return true; }
+            NLOHMANN_DEFINE_TYPE_INTRUSIVE(marker)
+        };
+    }
+
+    ns::marker m{};
+    nlohmann::json j = m; // {}
+    ```
+
 !!! note "No macro for non-default-constructible types"
 
     There is currently no `NLOHMANN_DEFINE_TYPE_*`-style macro for types that are not

docs/mkdocs/docs/features/binary_formats/bjdata.md

@@ -116,18 +116,22 @@ The library uses the following mapping from JSON values types to BJData types ac
     ```
 
     Likewise, when a JSON object in the above form is serialized using
-    [`to_bjdata`](../../api/basic_json/to_bjdata.md), it is automatically converted into a compact BJData ND-array. When
-    the 1-dimensional vector stored in `"_ArraySize_"` contains a single integer or two integers with one being 1, a
-    regular 1-D optimized array is generated instead.
+    [`to_bjdata`](../../api/basic_json/to_bjdata.md), it is automatically converted into a compact BJData ND-array.
 
-    An object is only converted if the annotation actually describes a packed array; otherwise it is serialized as a
-    regular JSON object. This requires all of the following:
+    When parsing, an ND-array whose dimension vector is empty, contains a single integer, contains two integers with the
+    first being 1, or contains a 0 is returned as a regular (possibly empty) array rather than an annotated object.
+
+    An object is only converted if the annotation describes a packed array that is parsed back into the same annotated
+    object; otherwise it is serialized as a regular JSON object, so the annotation is never lost in a round trip. This requires
+    all of the following:
 
     - `"_ArrayType_"` is one of `uint8`, `int8`, `uint16`, `int16`, `uint32`, `int32`, `uint64`, `int64`, `single`,
       `double`, `char`, or `byte`,
     - `"_ArraySize_"` is an array, since the dimensions are written as the ND-array header's length,
-    - every entry of `"_ArraySize_"` is a non-negative integer, and their product is representable as a `std::size_t`,
-    - `"_ArrayData_"` holds exactly that many elements, and
+    - `"_ArraySize_"` has at least two entries and is not a 1×N row vector (first entry 1), since other shapes are
+      parsed back as a regular array,
+    - every entry of `"_ArraySize_"` is a positive integer, and their product is representable as a `std::size_t`,
+    - `"_ArrayData_"` is an array holding exactly that many elements, and
     - every element of `"_ArrayData_"` is a number of the kind named by `"_ArrayType_"` (a floating-point number for
       `single` and `double`, an integer otherwise).
 
@@ -204,6 +208,16 @@ The library maps BJData types to JSON value types as follows:
 
     The mapping is **complete** in the sense that any BJData value can be converted to a JSON value.
 
+!!! info "Round trips"
+
+    A value returned by [`from_bjdata`](../../api/basic_json/from_bjdata.md) can be serialized with
+    [`to_bjdata`](../../api/basic_json/to_bjdata.md) using any combination of options and parsed back into an equal
+    value, and serializing that value again with the same options produces the same bytes. The exception is binary
+    values: they are only written as an optimized binary array (`[$B`) if Draft 3 is enabled and both `use_size` and
+    `use_type` are set. Otherwise, they are written as arrays of integers and parsed back as such (see the notes on
+    binary values above), and serializing such an array again may choose different, but equally valid, type markers.
+    The bytes can then differ, but parsing them again yields the same value.
+
 ??? example
 
     ```cpp

docs/mkdocs/docs/features/binary_formats/bon8.md

@@ -0,0 +1,159 @@
+# BON8
+
+BON8 (Binary Object Notation 8) is a compact binary serialization format for JSON values. It uses the byte values that
+cannot begin a UTF-8 character as type markers, so strings are stored as plain UTF-8 without a length prefix: a string
+ends at the first byte that cannot continue it. Integers from -10 to 39, `true`, `false`, `null`, and the floating-point
+values -1.0, 0.0, and 1.0 take a single byte, and arrays and objects with up to four elements need no terminator.
+
+!!! abstract "References"
+
+    - [BON8 specification](https://github.com/hikoworks/hikogui/blob/main/docs/BON8.md)
+    - [Reference implementation](https://github.com/hikoworks/hikogui/blob/main/src/hikogui/codec/BON8.hpp) in HikoGUI
+
+## Serialization
+
+The library uses the following mapping from JSON values types to BON8 types according to the BON8 specification:
+
+| JSON value type | value/range                                  | BON8 type                     | first byte |
+|-----------------|----------------------------------------------|-------------------------------|------------|
+| null            | `null`                                       | null                          | 0xFA       |
+| boolean         | `true`                                       | true                          | 0xF9       |
+| boolean         | `false`                                      | false                         | 0xF8       |
+| number_integer  | -9223372036854775808..-2147483649            | int64                         | 0x8D       |
+| number_integer  | -2147483648..-33818507                       | int32                         | 0x8C       |
+| number_integer  | -33818506..-264075                           | 4-byte negative integer       | 0xF0..0xF7 |
+| number_integer  | -264074..-1931                               | 3-byte negative integer       | 0xE0..0xEF |
+| number_integer  | -1930..-11                                   | 2-byte negative integer       | 0xC2..0xDF |
+| number_integer  | -10..-1                                      | 1-byte negative integer       | 0xB8..0xC1 |
+| number_integer  | 0..39                                        | 1-byte positive integer       | 0x90..0xB7 |
+| number_integer  | 40..3879                                     | 2-byte positive integer       | 0xC2..0xDF |
+| number_integer  | 3880..528167                                 | 3-byte positive integer       | 0xE0..0xEF |
+| number_integer  | 528168..67637031                             | 4-byte positive integer       | 0xF0..0xF7 |
+| number_integer  | 67637032..2147483647                         | int32                         | 0x8C       |
+| number_integer  | 2147483648..9223372036854775807              | int64                         | 0x8D       |
+| number_unsigned | 0..39                                        | 1-byte positive integer       | 0x90..0xB7 |
+| number_unsigned | 40..3879                                     | 2-byte positive integer       | 0xC2..0xDF |
+| number_unsigned | 3880..528167                                 | 3-byte positive integer       | 0xE0..0xEF |
+| number_unsigned | 528168..67637031                             | 4-byte positive integer       | 0xF0..0xF7 |
+| number_unsigned | 67637032..2147483647                         | int32                         | 0x8C       |
+| number_unsigned | 2147483648..9223372036854775807              | int64                         | 0x8D       |
+| number_float    | `-1.0`                                       | -1.0                          | 0xFB       |
+| number_float    | `0.0`                                        | 0.0                           | 0xFC       |
+| number_float    | `1.0`                                        | 1.0                           | 0xFD       |
+| number_float    | *any other value representable by a float*   | binary32                      | 0x8E       |
+| number_float    | *any value NOT representable by a float*     | binary64                      | 0x8F       |
+| string          | *empty*                                      | end of string                 | 0xFF       |
+| string          | *non-empty*                                  | UTF-8 string                  | 0x00..0x7F, 0xC2..0xF4 |
+| array           | *size*: 0..4                                 | array with count              | 0x80..0x84 |
+| array           | *size*: 5 or more                            | array (terminated by 0xFE)    | 0x85       |
+| object          | *size*: 0..4                                 | object with count             | 0x86..0x8A |
+| object          | *size*: 5 or more                            | object (terminated by 0xFE)   | 0x8B       |
+| binary          | *size*: 0..4                                 | array with count              | 0x80..0x84 |
+| binary          | *size*: 5 or more                            | array (terminated by 0xFE)    | 0x85       |
+
+An integer that takes 2 to 4 bytes starts with a UTF-8 lead byte (0xC2..0xF7) that is followed by a byte that cannot
+continue a UTF-8 character: 0x00..0x7F for positive and 0xC0..0xFF for negative integers. A string is terminated by
+0xFF only if it is empty, if another string follows it, or if it is the last value of the message; otherwise, the first
+byte of the next value ends it.
+
+!!! success "Complete mapping"
+
+    Except for the values listed below, any JSON value can be converted to a BON8 value.
+
+    Any BON8 output created by `to_bon8` can be successfully parsed by `from_bon8`.
+
+!!! warning "Unsupported values"
+
+    The following values can **not** be converted to a BON8 value:
+
+      - unsigned integers above 9223372036854775807, because BON8 has no unsigned 64-bit integer type
+        ([out_of_range.407](../../home/exceptions.md#jsonexceptionout_of_range407))
+      - strings that are not valid UTF-8, because the end of a string is determined from its encoding
+        ([type_error.316](../../home/exceptions.md#jsonexceptiontype_error316))
+
+!!! info "NaN/infinity handling"
+
+    `-0.0`, `Infinity`, and `-Infinity` are serialized as binary32 (type 0x8E, 5 bytes total). `NaN` is serialized as
+    the binary32 value 0x7F800001 that the specification recommends. This is in contrast to the
+    [dump](../../api/basic_json/dump.md) function which serializes NaN or Infinity to `null`.
+
+!!! warning "Binary values"
+
+    BON8 has no binary type. Binary values are serialized as arrays of integers (0..255), so they are read back as
+    arrays. The subtype is not serialized.
+
+!!! info "Canonical representation"
+
+    The output follows the specification's canonical representation rules: every value uses the shortest encoding,
+    floating-point numbers use binary32 whenever that loses no precision, and object keys are sorted by their UTF-8
+    code units. There are two exceptions:
+
+    - Strings are not normalized to Unicode Normalization Form C (NFC).
+    - Object keys are written in the order of the object type, which is sorted for `json`, but not for
+      [`ordered_json`](../../api/ordered_json.md).
+
+??? example
+
+    ```cpp
+    --8<-- "examples/to_bon8.cpp"
+    ```
+
+    Output:
+
+    ```c
+    --8<-- "examples/to_bon8.output"
+    ```
+
+## Deserialization
+
+The library maps BON8 types to JSON value types as follows:
+
+| BON8 type                     | JSON value type | first byte             |
+|-------------------------------|-----------------|------------------------|
+| UTF-8 string                  | string          | 0x00..0x7F             |
+| array with count              | array           | 0x80..0x84             |
+| array (terminated by 0xFE)    | array           | 0x85                   |
+| object with count             | object          | 0x86..0x8A             |
+| object (terminated by 0xFE)   | object          | 0x8B                   |
+| int32                         | number_unsigned or number_integer | 0x8C |
+| int64                         | number_unsigned or number_integer | 0x8D |
+| binary32                      | number_float    | 0x8E                   |
+| binary64                      | number_float    | 0x8F                   |
+| 1-byte positive integer       | number_unsigned | 0x90..0xB7             |
+| 1-byte negative integer       | number_integer  | 0xB8..0xC1             |
+| UTF-8 string                  | string          | 0xC2..0xF4, followed by 0x80..0xBF |
+| 2- to 4-byte positive integer | number_unsigned | 0xC2..0xF7, followed by 0x00..0x7F |
+| 2- to 4-byte negative integer | number_integer  | 0xC2..0xF7, followed by 0xC0..0xFF |
+| false                         | `false`         | 0xF8                   |
+| true                          | `true`          | 0xF9                   |
+| null                          | `null`          | 0xFA                   |
+| -1.0                          | number_float    | 0xFB                   |
+| 0.0                           | number_float    | 0xFC                   |
+| 1.0                           | number_float    | 0xFD                   |
+| empty string                  | string          | 0xFF                   |
+
+Non-negative integers are read as number_unsigned, negative integers as number_integer.
+
+!!! info
+
+    Values that do not use the canonical representation, such as integers with a longer encoding than necessary,
+    arrays and objects with up to four elements that are terminated by 0xFE, unsorted object keys, or a 0xFF after a
+    string that would also end without it, are accepted. A second 0xFF is not a terminator but an empty string.
+
+    Strings must be valid UTF-8, and the last string of a message must be terminated by 0xFF.
+
+!!! info
+
+    Any BON8 output created by `to_bon8` can be successfully parsed by `from_bon8`.
+
+??? example
+
+    ```cpp
+    --8<-- "examples/from_bon8.cpp"
+    ```
+
+    Output:
+
+    ```json
+    --8<-- "examples/from_bon8.output"
+    ```

docs/mkdocs/docs/features/binary_formats/bson.md

@@ -109,6 +109,15 @@ The library maps BSON record types to JSON value types as follows:
     If BSON input must be validated for strict specification compliance, validate it separately before passing it to
     `from_bson()`.
 
+!!! warning "UTF-8 validation of string values"
+
+    The BSON specification requires `string` values (type `0x02`) to be valid UTF-8. This library validates the
+    bytes of every such string at decode time and rejects ill-formed UTF-8 with a
+    [`parse_error.113`](../../home/exceptions.md#jsonexceptionparse_error113) exception (or, with `allow_exceptions`
+    set to `false`, a discarded value), rather than only failing later when the resulting value is dumped. Element
+    (key) names and `binary` values (type `0x05`) are unaffected and are never validated, since they are read
+    byte-by-byte as a C string, or are not required to hold text, respectively.
+
 ??? example
 
     ```cpp

docs/mkdocs/docs/features/binary_formats/cbor.md

@@ -176,9 +176,19 @@ The library maps CBOR types to JSON value types as follows:
 
     CBOR allows map keys of any type, whereas JSON only allows strings as keys in object values. Therefore, CBOR maps with keys other than UTF-8 strings are rejected.
 
+!!! warning "UTF-8 validation of text strings"
+
+    [RFC 8949, Section 3.1](https://www.rfc-editor.org/rfc/rfc8949.html#section-3.1) requires CBOR text strings
+    (major type 3) to be valid UTF-8. This library validates the bytes of every text string (object keys included) at
+    decode time and rejects ill-formed UTF-8 with a
+    [`parse_error.113`](../../home/exceptions.md#jsonexceptionparse_error113) exception (or, with
+    `allow_exceptions` set to `false`, a discarded value), rather than only failing later when the resulting value is
+    dumped. Byte strings (major type 2) are unaffected and are never validated, since they are not required to hold
+    text.
+
 !!! warning "Tagged items"
 
-    Tagged items (0xC0..0xDB) will throw a parse error by default. They can be ignored by passing `cbor_tag_handler_t::ignore` to function `from_cbor`, in which case the tag is skipped and the enclosed data item is parsed on its own. They can be stored by passing `cbor_tag_handler_t::store` to function `from_cbor`. Note that no tag is ever interpreted: for instance, a text string tagged with tag 0 (date/time) stays a string.
+    Tagged items (0xC0..0xDB) will throw a parse error by default. They can be ignored by passing `cbor_tag_handler_t::ignore` to function `from_cbor`, in which case the tag is skipped and the enclosed data item is parsed on its own. Passing `cbor_tag_handler_t::store` to function `from_cbor` stores tagged byte strings (for bytes 0xd8..0xdb) as binary values with the tag as subtype; other tagged values are read as if the tag were ignored. If several tags precede a byte string, only the innermost one is stored. Note that no tag is ever interpreted: for instance, a text string tagged with tag 0 (date/time) stays a string.
 
 ??? example
 

docs/mkdocs/docs/features/binary_formats/index.md

@@ -4,6 +4,7 @@ Though JSON is a ubiquitous data format, it is not a very compact format suitabl
 a network. Hence, the library supports
 
 - [BJData](bjdata.md) (Binary JData),
+- [BON8](bon8.md) (Binary Object Notation 8),
 - [BSON](bson.md) (Binary JSON),
 - [CBOR](cbor.md) (Concise Binary Object Representation),
 - [MessagePack](messagepack.md), and
@@ -18,6 +19,7 @@ to efficiently encode JSON values to byte vectors and to decode such vectors.
 | Format      | Serialization                                 | Deserialization                              |
 |-------------|-----------------------------------------------|----------------------------------------------|
 | BJData      | complete                                      | complete                                     |
+| BON8        | incomplete: no unsigned integers above int64  | complete                                     |
 | BSON        | incomplete: top-level value must be an object | incomplete, but all JSON types are supported |
 | CBOR        | complete                                      | incomplete, but all JSON types are supported |
 | MessagePack | complete                                      | complete                                     |
@@ -28,6 +30,7 @@ to efficiently encode JSON values to byte vectors and to decode such vectors.
 | Format      | Binary values | Binary subtypes |
 |-------------|---------------|-----------------|
 | BJData      | not supported | not supported   |
+| BON8        | not supported | not supported   |
 | BSON        | supported     | supported       |
 | CBOR        | supported     | supported       |
 | MessagePack | supported     | supported       |
@@ -42,6 +45,7 @@ See [binary values](../binary_values.md) for more information.
 | BJData             | 53.2 %      | 91.1 %       | 78.1 %            | 96.6 %        |
 | BJData (size)      | 58.6 %      | 92.1 %       | 86.7 %            | 97.4 %        |
 | BJData (size+type) | 58.6 %      | 92.1 %       | 86.5 %            | 97.4 %        |
+| BON8               | 50.5 %      | 83.8 %       | 63.5 %            | 87.5 %        |
 | BSON               | 85.8 %      | 95.2 %       | 95.8 %            | 106.7 %       |
 | CBOR               | 50.5 %      | 86.3 %       | 68.4 %            | 88.0 %        |
 | MessagePack        | 50.5 %      | 86.0 %       | 68.5 %            | 87.9 %        |

docs/mkdocs/docs/features/binary_formats/messagepack.md

@@ -65,6 +65,8 @@ specification:
       - arrays with more than 4294967295 elements
       - objects with more than 4294967295 elements
 
+    Serializing such a value throws [`out_of_range.412`](../../home/exceptions.md#jsonexceptionout_of_range412).
+
 !!! info "NaN/infinity handling"
 
     `NaN`, `Infinity`, and `-Infinity` are serialized as a MessagePack float 32 (type 0xCA, 5 bytes total),
@@ -136,6 +138,14 @@ The library maps MessagePack types to JSON value types as follows:
 
     Any MessagePack output created by `to_msgpack` can be successfully parsed by `from_msgpack`.
 
+!!! warning "UTF-8 validation of string values"
+
+    The MessagePack specification requires `str` values (`fixstr`, `str 8`, `str 16`, `str 32`) to be valid UTF-8.
+    This library validates the bytes of every such string (object keys included) at decode time and rejects
+    ill-formed UTF-8 with a [`parse_error.113`](../../home/exceptions.md#jsonexceptionparse_error113) exception (or,
+    with `allow_exceptions` set to `false`, a discarded value), rather than only failing later when the resulting
+    value is dumped. `bin`/`ext`/`fixext` values are unaffected and are never validated, since they are not required
+    to hold text.
 
 ??? example
 

docs/mkdocs/docs/features/binary_values.md

@@ -187,6 +187,41 @@ as an array of uint8 values. The library implements this translation.
     }
     ```
 
+### BON8
+
+[BON8](binary_formats/bon8.md) neither supports binary values nor subtypes. The library serializes binary values as an
+array of integers.
+
+??? example
+
+    Code:
+
+    ```cpp
+    // create a binary value of subtype 42 (will be ignored in BON8)
+    json j;
+    j["binary"] = json::binary({0xCA, 0xFE, 0xBA, 0xBE}, 42);
+
+    // convert to BON8
+    auto v = json::to_bon8(j);
+    ```
+
+    `v` is a `std::vector<std::uint8_t>` with the following 16 elements:
+
+    ```c
+    0x87                                     // object with 1 member
+        0x62 0x69 0x6E 0x61 0x72 0x79        // "binary"
+        0x84                                 // array with 4 elements
+            0xC3 0x22 0xC3 0x56 0xC3 0x12 0xC3 0x16  // content (each byte as a 2-byte integer)
+    ```
+
+    Note that the subtype is lost, and deserializing `v` would yield the following value:
+
+    ```json
+    {
+      "binary": [202, 254, 186, 190]
+    }
+    ```
+
 ### BSON
 
 [BSON](binary_formats/bson.md) supports binary values and subtypes. If a subtype is given, it is used and added as an

docs/mkdocs/docs/features/index.md

@@ -35,8 +35,8 @@ C++ types, and finally serialize it again.
 - [Serialization](serialization.md) — turn a value back into JSON text with [`dump`](../api/basic_json/dump.md),
   including pretty-printing and handling of non-ASCII and invalid UTF-8.
 - [Binary formats](binary_formats/index.md) — encode values more compactly as
-  [BJData](binary_formats/bjdata.md), [BSON](binary_formats/bson.md), [CBOR](binary_formats/cbor.md),
-  [MessagePack](binary_formats/messagepack.md), or [UBJSON](binary_formats/ubjson.md).
+  [BJData](binary_formats/bjdata.md), [BON8](binary_formats/bon8.md), [BSON](binary_formats/bson.md),
+  [CBOR](binary_formats/cbor.md), [MessagePack](binary_formats/messagepack.md), or [UBJSON](binary_formats/ubjson.md).
 - [Binary values](binary_values.md) — store and exchange raw byte sequences.
 
 ## How values are stored and configured

docs/mkdocs/docs/features/macros.md

@@ -91,6 +91,23 @@ security reasons (e.g., Intel Software Guard Extensions (SGX)).
 
 See [full documentation of `JSON_NO_IO`](../api/macros/json_no_io.md).
 
+## `JSON_NO_THREAD_LOCAL`
+
+When defined, the library does not use `#!cpp thread_local` storage. Copying a value and comparing two values then
+always avoid the call stack rather than descending into a bounded number of levels first, which is slower but yields the
+same values and the same comparisons.
+
+See [full documentation of `JSON_NO_THREAD_LOCAL`](../api/macros/json_no_thread_local.md).
+
+## `JSON_PRECISE_STREAM_POSITION`
+
+When defined to `1`, [`operator>>`](../api/operator_gtgt.md) and non-strict
+[`sax_parse`](../api/basic_json/sax_parse.md) leave an input stream positioned right after the parsed value, instead of
+also consuming the character that terminates a number. The default value is `0`, which preserves the existing behavior;
+this is planned to become the default in version 4.0.0.
+
+See [full documentation of `JSON_PRECISE_STREAM_POSITION`](../api/macros/json_precise_stream_position.md).
+
 ## `JSON_SKIP_LIBRARY_VERSION_CHECK`
 
 When defined, the library will not create a compiler warning when a different version of the library was already
@@ -105,6 +122,19 @@ using the library with compilers that do not fully support C++11 and may only wo
 
 See [full documentation of `JSON_SKIP_UNSUPPORTED_COMPILER_CHECK`](../api/macros/json_skip_unsupported_compiler_check.md).
 
+## `JSON_STRICT_NUL_HANDLING`
+
+When defined to `1`, a `'\0'` (NUL) byte anywhere in the input is rejected with `parse_error.101`, like any other
+unexpected byte, instead of being silently treated as end of input (see the
+[FAQ entry](../home/faq.md#nul-bytes-in-the-input) for background). The default value is `0`, which preserves the
+existing behavior; this is planned to become the default in version 4.0.0.
+
+The strict handling can also be enabled with the CMake option
+[`JSON_StrictNulHandling`](../integration/cmake.md#json_strictnulhandling) (`OFF` by default) which sets
+`JSON_STRICT_NUL_HANDLING` accordingly.
+
+See [full documentation of `JSON_STRICT_NUL_HANDLING`](../api/macros/json_strict_nul_handling.md).
+
 ## `JSON_THROW_USER(exception)`
 
 This macro overrides `#!cpp throw` calls inside the library. The argument is the exception to be thrown.

docs/mkdocs/docs/features/namespace.md

@@ -15,6 +15,11 @@ The complete default namespace name is derived as follows:
     - [`JSON_DIAGNOSTICS`](../api/macros/json_diagnostics.md) defined non-zero appends `_diag`.
     - [`JSON_USE_LEGACY_DISCARDED_VALUE_COMPARISON`](../api/macros/json_use_legacy_discarded_value_comparison.md)
       defined non-zero appends `_ldvcmp`.
+    - [`JSON_DIAGNOSTIC_POSITIONS`](../api/macros/json_diagnostic_positions.md) defined non-zero appends `_dp`.
+    - [`JSON_BRACE_INIT_COPY_SEMANTICS`](../api/macros/json_brace_init_copy_semantics.md) defined non-zero appends
+      `_bics`.
+    - [`JSON_PRECISE_STREAM_POSITION`](../api/macros/json_precise_stream_position.md) defined non-zero appends `_psp`.
+    - [`JSON_STRICT_NUL_HANDLING`](../api/macros/json_strict_nul_handling.md) defined non-zero appends `_snul`.
 - The inline namespace ends with the suffix `_v` followed by the 3 components of the version number separated by
   underscores. To omit the version component, see [Disabling the version component](#disabling-the-version-component)
   below.

docs/mkdocs/docs/features/object_order.md

@@ -51,12 +51,16 @@ If you do want to preserve the **insertion order**, you can use the type [`nlohm
     --8<-- "examples/ordered_json.output"
     ```
 
-Alternatively, you can use a more sophisticated ordered map like [`tsl::ordered_map`](https://github.com/Tessil/ordered-map) ([integration](https://github.com/nlohmann/json/issues/546#issuecomment-304447518)) or [`nlohmann::fifo_map`](https://github.com/nlohmann/fifo_map) ([integration](https://github.com/nlohmann/json/issues/485#issuecomment-333652309)).
+Alternatively, [`nlohmann::fifo_map`](https://github.com/nlohmann/fifo_map) also preserves the insertion order and, unlike [`ordered_map`](../api/ordered_map/index.md), keeps a lookup index, so it does not have the quadratic cost described below. It is used through a small adapter ([integration](https://github.com/nlohmann/json/issues/485#issuecomment-333652309)).
 
-The [`ordered_map`](../api/ordered_map.md) behind `nlohmann::ordered_json` is deliberately minimal and has no lookup
+If the order does not matter and you only want faster lookup, `boost::unordered_flat_map`, `absl::flat_hash_map`, `absl::node_hash_map`, and several other hash maps work through an adapter that restores the template argument order `basic_json` expects; see [Template Parameter Requirements](types/template_parameters.md#objecttype). Note these are *unordered*, not insertion-ordered.
+
+[`tsl::ordered_map`](https://github.com/Tessil/ordered-map) cannot be used: its iterators expose the mapped value as `const`, while `basic_json` needs to modify it in place.
+
+The [`ordered_map`](../api/ordered_map/index.md) behind `nlohmann::ordered_json` is deliberately minimal and has no lookup
 index, so every key access is a linear scan and building an object of `n` keys costs O(n²). This is unnoticeable at
 typical object sizes but becomes significant for objects with many thousands of keys; see
-[`ordered_map` complexity](../api/ordered_map.md#complexity). The alternatives above keep a lookup index and do not
+[`ordered_map` complexity](../api/ordered_map/index.md#complexity). The alternatives above keep a lookup index and do not
 have this cost.
 
 ### Notes on parsing

docs/mkdocs/docs/features/parsing/index.md

@@ -41,7 +41,8 @@ document followed by trailing bytes" is accepted rather than rejected. If you ar
 reject any input that is not exactly one JSON document, prefer `parse`.
 
 When using `operator>>` to read several concatenated values this way, a value that is a number must be followed by
-whitespace, because `operator>>` consumes the character that terminates a number — see the
+whitespace, because `operator>>` consumes the character that terminates a number, unless
+[`JSON_PRECISE_STREAM_POSITION`](../../api/macros/json_precise_stream_position.md) is defined to `1` — see the
 [`operator>>` notes](../../api/operator_gtgt.md#notes) for details and examples.
 
 ## SAX vs. DOM parsing

docs/mkdocs/docs/features/serialization.md

@@ -117,7 +117,7 @@ For the [{fmt}](https://github.com/fmtlib/fmt) library, the library ships a
 ## Serializing to other formats
 
 Besides JSON text, a value can also be serialized to the more compact [binary formats](binary_formats/index.md)
-(BJData, BSON, CBOR, MessagePack, UBJSON).
+(BJData, BON8, BSON, CBOR, MessagePack, UBJSON).
 
 ## See also
 

docs/mkdocs/docs/features/types/index.md

@@ -79,7 +79,8 @@ template<
     class NumberFloatType = double,
     template<typename U> class AllocatorType = std::allocator,
     template<typename T, typename SFINAE = void> class JSONSerializer = adl_serializer,
-    class BinaryType = std::vector<std::uint8_t>
+    class BinaryType = std::vector<std::uint8_t>,
+    class CustomBaseClass = void
 >
 class basic_json;
 ```
@@ -106,6 +107,10 @@ using number_float_t = NumberFloatType;
 using binary_t = nlohmann::byte_container_with_subtype<BinaryType>;
 ```
 
+Not every type can be passed for these template arguments: the library uses the resulting types in ways that imply a
+number of requirements, for instance that `StringType` is `char`-based or that `ArrayType` is vector-like. These
+requirements are collected in [Template Parameter Requirements](template_parameters.md).
+
 
 ## Objects
 

docs/mkdocs/docs/features/types/template_parameters.md

@@ -0,0 +1,751 @@
+# Template Parameter Requirements
+
+Class [`basic_json`](../../api/basic_json/index.md) is configurable through eleven template parameters. The library
+never formally states what a type passed for one of these parameters has to provide -- the requirements are implied by
+the way the library uses the resulting [`object_t`](../../api/basic_json/object_t.md),
+[`array_t`](../../api/basic_json/array_t.md), [`string_t`](../../api/basic_json/string_t.md), etc. This page collects
+these requirements so they do not have to be discovered by trial and error. Each section lists the concrete types
+that are known to work for that parameter and the ones that do not, checked against Boost 1.83, Abseil 20250127.0,
+Folly, EASTL 3.21, `ankerl::unordered_dense`, `phmap`, `gtl`, `robin_hood`, `tsl::ordered_map`, and Qt 6.
+
+## How to read this page
+
+Requirements are split into two groups:
+
+- **Always required** -- needed to instantiate `basic_json` at all, or needed by functions that virtually every program
+  uses (construction, element access, [`dump`](../../api/basic_json/dump.md)).
+- **Required for ...** -- only needed when a particular part of the API is instantiated. Member function templates are
+  only instantiated when they are used, so a type may be perfectly usable even though it does not satisfy these
+  requirements, as long as the corresponding functions are never called.
+
+!!! warning "Requirements are not checked"
+
+    Three requirements are checked with a `#!cpp static_assert`: the array iterator category, the width of
+    [`BinaryType`](#binarytype)'s `value_type`, and [`NumberUnsignedType`](#numberintegertype-and-numberunsignedtype)
+    being at least as wide as [`NumberIntegerType`](#numberintegertype-and-numberunsignedtype). The rest are not
+    diagnosed with dedicated error messages, and violating most of them results in a compiler error somewhere inside
+    the library. Four violations are not caught at compile time at all:
+
+    - A [`StringType`](#stringtype) whose `data()` is not null-terminated compiles and silently misparses numbers,
+      because the lexer hands the buffer to `#!cpp std::strtoull`/`#!cpp std::strtoll`/`#!cpp std::strtod`.
+    - A stateful [`AllocatorType`](#allocatortype) compiles and silently ignores its state: allocation, deallocation,
+      and [`get_allocator()`](../../api/basic_json/get_allocator.md) each use a different default-constructed instance.
+    - The two [cross-specialization conversions](#cross-specialization-conversions) below. These abort on an assertion
+      in a normal build, and only fail silently under `#!cpp NDEBUG`.
+
+## Overview
+
+| Template parameter                                                | Default                           | Notable substitutes                                                   |
+|-------------------------------------------------------------------|-----------------------------------|-----------------------------------------------------------------------|
+| [`ObjectType`](#objecttype)                                       | `std::map`                        | [`nlohmann::ordered_map`](../../api/ordered_map/index.md), Abseil hash maps |
+| [`ArrayType`](#arraytype)                                         | `std::vector`                     | `#!cpp std::deque`                                                    |
+| [`StringType`](#stringtype)                                       | `std::string`                     | `std::string`-like types over `char`                                  |
+| [`BooleanType`](#booleantype)                                     | `bool`                            | none worth using                                                      |
+| [`NumberIntegerType`](#numberintegertype-and-numberunsignedtype)  | `std::int64_t`                    | any signed integer type                                               |
+| [`NumberUnsignedType`](#numberintegertype-and-numberunsignedtype) | `std::uint64_t`                   | any unsigned integer type at least as wide as `NumberIntegerType`     |
+| [`NumberFloatType`](#numberfloattype)                             | `double`                          | `float` (`long double`: no binary formats)                            |
+| [`AllocatorType`](#allocatortype)                                 | `std::allocator`                  | stateless allocators                                                  |
+| [`JSONSerializer`](#jsonserializer)                               | `adl_serializer`                  | serializers with the same interface                                   |
+| [`BinaryType`](#binarytype)                                       | `#!cpp std::vector<std::uint8_t>` | `#!cpp std::vector<char>`                                             |
+| [`CustomBaseClass`](#custombaseclass)                             | `void`                            | any default-constructible class                                       |
+
+!!! warning "Third-party containers and incomplete types"
+
+    `object_t` is instantiated inside the definition of `basic_json` -- it is probed for a `key_compare` member to
+    form [`object_comparator_t`](../../api/basic_json/object_comparator_t.md) -- i.e. while `basic_json` is still an
+    incomplete type. `#!cpp std::map` is required by the standard to support incomplete mapped types; most
+    third-party maps are not, and inspecting the mapped type at class scope (for instance with
+    `#!cpp std::is_trivially_move_assignable`) makes them unusable as `ObjectType`, no matter how their template
+    arguments are adapted. This rules out `absl::btree_map`, `phmap::btree_map`, `gtl::btree_map`,
+    `robin_hood::unordered_node_map`, `folly::F14FastMap`, and `eastl::hash_map`.
+
+    `array_t` is only *named* in the class definition and is not instantiated until `basic_json` is complete, so an
+    `ArrayType` that inspects its value type at class scope is generally fine -- `boost::container::small_vector` and
+    `static_vector` both reject incomplete value types yet work here. `absl::InlinedVector` is the exception: the
+    `#!cpp std::is_trivially_move_assignable<basic_json>` it evaluates while instantiating itself re-enters the
+    library's own trait machinery mid-instantiation.
+
+!!! note "Folly requires C++20"
+
+    Folly's headers use `#!cpp consteval` and `#!cpp std::type_identity`, so any `basic_json` specialization that
+    names a Folly type has to be compiled as C++20 or later, whatever the rest of the library supports.
+
+## `ObjectType`
+
+`ObjectType` is instantiated as
+
+```cpp
+using object_t = ObjectType<StringType,                                    // key_type
+                            basic_json,                                    // mapped_type
+                            default_object_comparator_t,                   // key_compare
+                            AllocatorType<std::pair<const StringType,
+                                                    basic_json>>>;         // allocator_type
+```
+
+i.e., the template arguments follow the order and meaning of `std::map`.
+
+### Always required
+
+- The template must be usable with **four** type arguments in the order shown above. The third argument is a
+  **comparator**; containers that expect something else in this position (e.g., a hash function) need an alias template
+  or wrapper -- see [Notes](#notes).
+- An optional member type `key_compare`. If it is present it becomes
+  [`object_comparator_t`](../../api/basic_json/object_comparator_t.md); otherwise
+  [`default_object_comparator_t`](../../api/basic_json/default_object_comparator_t.md) is used.
+- Member types `key_type`, `mapped_type`, `value_type`, and `iterator`.
+- `value_type` must behave like `#!cpp std::pair<const key_type, mapped_type>`; the library accesses `.first` and
+  `.second` on it.
+- `iterator` must be default-constructible and satisfy
+  [LegacyBidirectionalIterator](https://en.cppreference.com/w/cpp/named_req/BidirectionalIterator). The type returned
+  by `cbegin()`/`cend()` must satisfy the same requirements.
+- Constructors: default, copy, move, and from an iterator range `(first, last)`.
+- Member functions `begin()`, `end()`, `cbegin()`, `cend()`, `empty()`, `size()`, `max_size()`, `clear()`,
+  `find(key)`, `count(key)`, `emplace(key, value)`, `insert(value_type)`, `insert(first, last)`, `operator[](key)`,
+  `erase(iterator)`, and `erase(first, last)`. `erase(iterator)` may return the following iterator or `#!cpp void`;
+  in the latter case the library computes the successor itself, before erasing.
+- `erase(key)` is **optional**: if the container does not provide one, the library falls back to `find(key)` followed
+  by `erase(iterator)`.
+- `at(key)` is required only by [`to_ubjson`](../../api/basic_json/to_ubjson.md) and
+  [`to_bjdata`](../../api/basic_json/to_bjdata.md), but every container tried here provides it.
+- `emplace` and `insert(value_type)` must return `#!cpp std::pair<iterator, bool>` and must have **unique-key**
+  semantics; multimaps cannot be used.
+- The type must be swappable (via `std::swap` or an ADL `swap`).
+- The comparison operators `==` and `<`; `!=`, `<=`, `>`, and `>=` are derived from them. Where the library uses
+  three-way comparison (C++20), `==` and `<=>` are required **instead** -- the six two-way operators do not satisfy
+  it. They implement [`basic_json`'s comparison operators](../../api/basic_json/operator_eq.md).
+
+### Required for heterogeneous key lookup
+
+The overloads of [`at`](../../api/basic_json/at.md), [`operator[]`](../../api/basic_json/operator%5B%5D.md),
+[`find`](../../api/basic_json/find.md), [`contains`](../../api/basic_json/contains.md),
+[`count`](../../api/basic_json/count.md), [`erase`](../../api/basic_json/erase.md), and
+[`value`](../../api/basic_json/value.md) that accept a key type other than `object_t::key_type` require
+
+- a **transparent** comparator, i.e. [`object_comparator_t`](../../api/basic_json/object_comparator_t.md) has a member
+  type `is_transparent` (this is why the default comparator is `#!cpp std::less<>` since C++14), and
+- corresponding heterogeneous `find`, `count`, `erase`, and `operator[]` overloads on the container.
+
+### Notes
+
+#### `std::unordered_map` needs an adapter
+
+`#!cpp std::unordered_map` cannot be passed directly: its third template parameter is a hash function, but
+`basic_json` passes a comparator in that position. An alias template or wrapper that restores the expected argument
+order makes it usable:
+
+```cpp
+template<class Key, class T, class IgnoredCompare, class Allocator>
+struct unordered_map_object
+    : std::unordered_map<Key, T, std::hash<Key>, std::equal_to<Key>, Allocator>
+{
+    using base_t = std::unordered_map<Key, T, std::hash<Key>, std::equal_to<Key>, Allocator>;
+    using base_t::base_t;
+};
+
+using unordered_json = nlohmann::basic_json<unordered_map_object>;
+```
+
+Whether `#!cpp std::unordered_map` can be instantiated at all depends on the standard library: `object_t` is formed
+while `basic_json` is still incomplete (see the warning above), and libstdc++ 9 needs the size of the mapped type to
+instantiate the hash map's node type, so the adapter does not compile there. Newer libstdc++ versions, and the hash
+maps listed below, do not have that problem.
+
+The adapter above works verbatim for Abseil's, Boost's, `phmap`'s and `gtl`'s hash maps, which all place the hash
+function third and take a `#!cpp std::pair<const Key, T>` allocator fifth. Two need a different adapter:
+
+- `ankerl::unordered_dense` expects an allocator over `#!cpp std::pair<Key, T>` (non-const key), so the allocator has
+  to be rebound to that or dropped.
+- `robin_hood`'s fifth parameter is the non-type `MaxLoadFactor100`, so its adapter must drop the allocator entirely.
+
+None of these hash maps defines `key_compare`, so all of them additionally rely on `object_comparator_t` falling back
+to [`default_object_comparator_t`](../../api/basic_json/default_object_comparator_t.md); see
+[`object_comparator_t`](../../api/basic_json/object_comparator_t.md).
+
+#### Abseil hash maps
+
+`absl::flat_hash_map` and `absl::node_hash_map` tolerate an incomplete value type, but they take a hash function as
+their third template argument. The same adapter as for `#!cpp std::unordered_map` makes them usable:
+
+```cpp
+template<class Key, class T, class IgnoredCompare, class Allocator>
+struct flat_hash_object
+    : absl::flat_hash_map<Key, T, absl::Hash<Key>, std::equal_to<Key>, Allocator>
+{
+    using base_t = absl::flat_hash_map<Key, T, absl::Hash<Key>, std::equal_to<Key>, Allocator>;
+    using base_t::base_t;
+};
+
+using flat_hash_json = nlohmann::basic_json<flat_hash_object>;
+```
+
+`absl::node_hash_map` keeps references to the mapped values valid across insertions; `absl::flat_hash_map` does not,
+which makes it behave like [`ordered_json`](../../api/ordered_json.md) with respect to
+[iterator invalidation](../../api/basic_json/index.md#iterator-invalidation). Both expose a `capacity()` member
+function, so [`JSON_DIAGNOSTICS`](../../api/macros/json_diagnostics.md) treats them conservatively and keeps the
+parent pointers correct either way.
+
+#### Iteration order
+
+The library never relies on the container's iteration order for correctness; it does determine the order in which
+object keys are serialized by [`dump`](../../api/basic_json/dump.md) and visited by
+[`items`](../../api/basic_json/items.md). See [Object Order](../object_order.md).
+
+#### `capacity()` marks a container as insertion-ordered
+
+With [`JSON_DIAGNOSTICS`](../../api/macros/json_diagnostics.md) enabled, the library detects insertion-ordered maps by
+probing for a `capacity()` member function (`nlohmann::ordered_map` inherits it from `std::vector`) and refreshes all
+parent pointers after every insertion. An `ObjectType` that happens to have a `capacity()` member is therefore treated
+conservatively -- this is correct, but slower.
+
+#### Key order and duplicate keys
+
+The library does not sort or de-duplicate keys itself; the behavior described in
+[`object_t`](../../api/basic_json/object_t.md) is entirely the behavior of the chosen container.
+
+!!! tip "Reference implementation"
+
+    `docs/mkdocs/docs/examples/custom_object_type.hpp` wraps a private `#!cpp std::map` and satisfies every
+    requirement above. It does not define `key_compare`, so `object_comparator_t` falls back to
+    [`default_object_comparator_t`](../../api/basic_json/default_object_comparator_t.md) -- a good starting point for
+    a custom `ObjectType`.
+
+    ```cpp
+    --8<-- "examples/custom_object_type.hpp"
+    ```
+
+??? example "Compiling and using it"
+
+    ```cpp
+    --8<-- "examples/custom_object_type.cpp"
+    ```
+
+    Output:
+
+    ```json
+    --8<-- "examples/custom_object_type.output"
+    ```
+
+### Compatible containers
+
+| Container                                                                        | Notes                                                                         |
+|----------------------------------------------------------------------------------|-------------------------------------------------------------------------------|
+| `#!cpp std::map` (default)                                                       |                                                                               |
+| [`nlohmann::ordered_map`](../../api/ordered_map/index.md)                              | used by [`ordered_json`](../../api/ordered_json.md); keeps insertion order    |
+| [`nlohmann::fifo_map`](https://github.com/nlohmann/fifo_map)                     | keeps insertion order; adapter puts `fifo_map_compare` in the comparator slot |
+| `boost::container::map`, `boost::container::flat_map`                            | no adapter needed                                                             |
+| `#!cpp std::unordered_map`                                                       | through the adapter above; not with libstdc++ 9, see the note                 |
+| `boost::unordered_map`, `boost::unordered_flat_map`, `boost::unordered_node_map` | through the adapter above                                                     |
+| `absl::flat_hash_map`, `absl::node_hash_map`                                     | through the adapter above; `flat_hash_map` moves mapped values on rehash      |
+| `phmap::flat_hash_map`, `phmap::node_hash_map`, `gtl::flat_hash_map`             | through the adapter above                                                     |
+| `ankerl::unordered_dense::map` and `segmented_map`                               | adapter must rebind or drop the allocator                                     |
+| `robin_hood::unordered_flat_map`                                                 | adapter must drop the allocator                                               |
+| `folly::F14NodeMap`                                                              | through the adapter above; requires C++20, see the note above                 |
+| `folly::sorted_vector_map`                                                       | alias must drop the allocator, whose value type it disagrees on               |
+
+### Containers that cannot be used
+
+| Container                                                                | Reason                                                                                                              |
+|--------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|
+| `absl::btree_map`, `phmap::btree_map`, `gtl::btree_map`                  | require a complete mapped type                                                                                      |
+| `robin_hood::unordered_node_map`, `folly::F14FastMap`, `eastl::hash_map` | require a complete mapped type                                                                                      |
+| `eastl::map`                                                             | EASTL iterators do not work with `#!cpp std::iterator_traits`                                                       |
+| `tsl::ordered_map`                                                       | its iterators expose the mapped value as `#!cpp const`                                                              |
+| `QMap`                                                                   | no `value_type` member type                                                                                         |
+| `QHash`                                                                  | its `value_type` is the mapped type rather than a key/value pair, and its iterators dereference to the mapped value |
+| `#!cpp std::multimap`, `#!cpp std::unordered_multimap`                   | `emplace` does not return `#!cpp std::pair<iterator, bool>`                                                         |
+
+## `ArrayType`
+
+`ArrayType` is instantiated as
+
+```cpp
+using array_t = ArrayType<basic_json, AllocatorType<basic_json>>;
+```
+
+### Always required
+
+- The template must be usable with **two** type arguments (value type and allocator).
+- Member types `value_type` and `iterator`.
+- Constructors: default, copy, and move; and from an iterator range `(first, last)`.
+- Member functions `begin()`, `end()`, `cbegin()`, `cend()`, `empty()`, `size()`, `max_size()`, `clear()`,
+  `operator[](size_type)`, `back()`, `push_back()`, `emplace_back()`, `pop_back()`, `resize()`,
+  `insert()` (single element, count, and range), `erase(pos)`, and `erase(first, last)`.
+  `basic_json::insert(pos, initializer_list)` goes through the range overload, so no initializer-list `insert` is
+  needed. `at(size_type)` is **not** required: [`basic_json::at(size_type)`](../../api/basic_json/at.md) checks the
+  index itself and then uses `operator[]`.
+- `iterator` must be default-constructible, and it as well as the type returned by `cbegin()`/`cend()` must satisfy
+  [LegacyRandomAccessIterator](https://en.cppreference.com/w/cpp/named_req/RandomAccessIterator).
+  A `#!cpp static_assert` only checks for
+  [LegacyBidirectionalIterator](https://en.cppreference.com/w/cpp/named_req/BidirectionalIterator), but
+  [`dump`](../../api/basic_json/dump.md) (`cend() - 1`),
+  [`erase(idx)`](../../api/basic_json/erase.md) (`begin() + idx`), and the random-access operations of
+  [`basic_json::iterator`](../../api/basic_json/begin.md) require random access.
+- The comparison operators, as for [`ObjectType`](#objecttype): `==` and `<`, or `==` and `<=>` under C++20.
+
+### Required for individual functions
+
+- A member type `value_type`, for [`to_bson`](../../api/basic_json/to_bson.md) of an array.
+- A constructor from `(count, value)`, for
+  [`basic_json(size_type, const basic_json&)`](../../api/basic_json/basic_json.md).
+- Swappability, via `#!cpp std::swap` or an ADL `swap`, for [`swap(array_t&)`](../../api/basic_json/swap.md).
+
+!!! note "`capacity()` is optional"
+
+    With [`JSON_DIAGNOSTICS`](../../api/macros/json_diagnostics.md) enabled, the library reads `array_t::capacity()`
+    to find out whether adding an element reallocated the array and moved its elements, which would invalidate the
+    parent pointers. An array type without a `capacity()` member function is handled conservatively: the parent
+    pointers of all elements are refreshed after every insertion, which makes adding *n* elements cost O(*n*²). Only
+    diagnostics builds pay this; without them `capacity()` is never called.
+
+!!! tip "Reference implementation"
+
+    `docs/mkdocs/docs/examples/custom_array_type.hpp` wraps a private `#!cpp std::vector` and satisfies every
+    requirement above -- a good starting point for a custom `ArrayType`.
+
+    ```cpp
+    --8<-- "examples/custom_array_type.hpp"
+    ```
+
+??? example "Compiling and using it"
+
+    ```cpp
+    --8<-- "examples/custom_array_type.cpp"
+    ```
+
+    Output:
+
+    ```json
+    --8<-- "examples/custom_array_type.output"
+    ```
+
+### Compatible containers
+
+| Container                                               | Notes                                                                                     |
+|---------------------------------------------------------|-------------------------------------------------------------------------------------------|
+| `#!cpp std::vector` (default)                           |                                                                                           |
+| `#!cpp std::deque`                                      | references survive appends, but not insertions elsewhere; see the `capacity()` note above |
+| `#!cpp std::pmr::vector`                                | through an alias, as the allocator comes from `AllocatorType` instead                     |
+| `boost::container::vector`, `deque`, `devector`         |                                                                                           |
+| `boost::container::stable_vector`                       | the only one tried that keeps references valid across *every* insertion                   |
+| `boost::container::small_vector`, `folly::small_vector` | through an alias that fixes the inline capacity                                           |
+| `boost::container::static_vector`                       | through the same kind of alias, for arrays that stay within the fixed capacity            |
+| `folly::fbvector`                                       | requires C++20, see the note above                                                        |
+
+### Containers that cannot be used
+
+| Container                           | Reason                                                                                        |
+|-------------------------------------|-----------------------------------------------------------------------------------------------|
+| `#!cpp std::list`                   | no `operator[]`, and no random-access iterators                                               |
+| `eastl::vector`, `QList`, `QVector` | no `max_size()`; they handle the incomplete value type fine                                   |
+| `absl::InlinedVector`               | requires a complete value type, see the note above                                            |
+| `absl::FixedArray`                  | the size is fixed at construction, so `resize`, `push_back`, `insert` and `erase` are missing |
+
+## `StringType`
+
+`StringType` is used **both** for JSON string values and for the keys of JSON objects
+(`string_t` and `object_t::key_type`).
+
+### Always required
+
+- A member type `value_type` that is one byte wide and `char`-compatible. The library stores and processes UTF-8
+  encoded `char` data and hands `data()` to `#!cpp std::strtoull`/`#!cpp std::strtoll`.
+  `#!cpp std::wstring`, `#!cpp std::u16string`, and `#!cpp std::u32string` are **not** valid choices; see the FAQ on
+  [wide string handling](../../home/faq.md#wide-string-handling).
+- Constructors: default, copy, move, from `#!cpp const char*` (which must not be `#!cpp explicit`), from
+  `#!cpp (const char*, size_type)`, and from `#!cpp (size_type, char)`; and copy or move assignment.
+- Member functions `size()`, `clear()`, `resize(n, c)`, `data()`, `push_back(char)`, and `operator[]`
+  (const and non-const, returning references). `c_str()` and `back()` are **not** required.
+- `data()` must return a pointer to a contiguous, **null-terminated** buffer -- the parser hands it to
+  `#!cpp std::strtoull`. A type whose `data()` is not null-terminated does not fail to compile; it silently
+  misparses numbers.
+- `append(const char*, size_type)`, used by [`dump`](../../api/basic_json/dump.md), and `append(const StringType&)`,
+  used by the CBOR reader for indefinite-length strings. The library's internal string concatenation additionally has
+  to append a `#!cpp char` and a `#!cpp const char*`; for each it selects between `append(arg)`, `#!cpp operator+=`,
+  `append(first, last)`, and `append(data, size)`.
+- The comparison operator `==` against another `StringType`, and `<` for use as a key of the chosen
+  [`ObjectType`](#objecttype) (with the default comparator, `#!cpp std::less<>` must be able to compare two
+  `StringType` values, and a `StringType` with the key types used for lookup). `!=` is never applied to a
+  `StringType`, and `==` against `#!cpp const char*` is resolved by the implicit `#!cpp const char*` constructor.
+
+### Required for the binary formats
+
+- `resize(n)`, used by the readers to make room for a block of bytes.
+- Non-const `operator[]`, into which the readers `#!cpp std::memcpy` those bytes. A non-`#!cpp const` `data()` would
+  serve just as well, but `#!cpp std::string` has only had one since C++17, and the library still supports C++11.
+
+### Required for JSON Pointer, `flatten`, and `diff`
+
+- A static member `npos` and the member function `find_first_of(char, size_type)` -- together with `data()`,
+  `reserve(n)`, and `append(const char*, size_type)` they implement the escaping and unescaping of reference tokens
+  described in RFC 6901. Neither `find(const StringType&, size_type)`, nor `substr(pos, count)`, nor
+  `replace(pos, count, const StringType&)` is required.
+- `empty()`.
+- `begin()` and `end()` -- used by
+  [`operator[](const json_pointer&)`](../../api/basic_json/operator%5B%5D.md) to decide whether a reference token
+  denotes an array index.
+
+### Required for other functionality
+
+| Functionality                                                                                                                     | Additional requirement                                                                                                                                                                       |
+|-----------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| [`diff`](../../api/basic_json/diff.md), [`items`](../../api/basic_json/items.md), [`std::hash`](../../api/basic_json/std_hash.md) | conversion of a `#!cpp std::size_t` to `StringType`: either assignability from the result of `#!cpp std::to_string`, or an ADL overload `#!cpp void int_to_string(StringType&, std::size_t)` |
+| [`std::hash<basic_json>`](../../api/basic_json/std_hash.md)                                                                       | additionally a specialization of `#!cpp std::hash<StringType>`                                                                                                                               |
+| [`to_bson`](../../api/basic_json/to_bson.md)                                                                                      | `find(value_type)` and `npos`                                                                                                                                                                |
+| [`parse`](../../api/basic_json/parse.md) from a `string_t`                                                                        | the input adapters must accept it; otherwise pass a character range                                                                                                                          |
+| `#!cpp operator<<(std::ostream&, const json_pointer&)`                                                                            | streamability to `#!cpp std::ostream`                                                                                                                                                        |
+| exception messages                                                                                                                | `data()` and `size()`, or `begin()` and `end()`                                                                                                                                              |
+
+### Compatible types
+
+| Type                                                            | Notes                                                                                                                                                                                                                                         |
+|-----------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `#!cpp std::string` (default)                                   |                                                                                                                                                                                                                                               |
+| `#!cpp std::basic_string` with a custom **stateless** allocator |                                                                                                                                                                                                                                               |
+| `#!cpp std::pmr::string`                                        | see the warning below before relying on the memory resource                                                                                                                                                                                   |
+| `boost::container::string`                                      | needs a user-supplied `#!cpp std::hash` specialization (Boost provides `boost::hash` instead)                                                                                                                                                 |
+| `folly::fbstring`                                               | requires C++20, see the note above                                                                                                                                                                                                            |
+| `eastl::string`                                                 | needs a user-supplied `#!cpp std::hash` and an ADL `int_to_string` (it is not assignable from a `#!cpp std::string`); [`parse`](../../api/basic_json/parse.md) does not accept it directly -- pass a character range or a `#!cpp std::string` |
+| a custom string class in a user-defined namespace               | if the requirements above are met                                                                                                                                                                                                             |
+
+### Types that cannot be used
+
+| Type                                                                 | Reason                                                                                                  |
+|----------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
+| `#!cpp std::wstring`, `#!cpp std::u16string`, `#!cpp std::u32string` | the character type is not one byte wide                                                                 |
+| `#!cpp std::u8string`                                                | one byte wide, but `#!cpp char8_t` is not `#!cpp char`-compatible                                       |
+| `absl::Cord`                                                         | no `value_type`, and the storage is not contiguous                                                      |
+| `QString`                                                            | no `append(const char*, size_type)`; its `QChar` is also two bytes wide, though that is never diagnosed |
+
+!!! warning "A `std::pmr::string` mostly does not use the memory resource you choose"
+
+    `basic_json` cannot be given an allocator or a memory resource. `AllocatorType` is default-constructed at every
+    allocation and has to be stateless (see [`AllocatorType`](#allocatortype)), and string values the library creates
+    are constructed with their own default allocator. So:
+
+    - Every string the library itself produces -- from [`parse`](../../api/basic_json/parse.md), from
+      [`dump`](../../api/basic_json/dump.md), or by default construction -- allocates from
+      `#!cpp std::pmr::get_default_resource()`.
+    - **Copying** an arena-backed string into a value silently drops its memory resource: the copy lands on the
+      default resource, because `#!cpp std::pmr::polymorphic_allocator` does not propagate on copy construction.
+      Nothing warns about this.
+    - **Moving** one in does keep it, and later growth still allocates from that arena -- but it does not survive a
+      copy of the enclosing `basic_json`.
+    - Passing `#!cpp std::pmr::polymorphic_allocator` as `AllocatorType` does not work around any of this; it does
+      not compile.
+
+    Apart from moving a string in, the only way to redirect these allocations is the process-global
+    `#!cpp std::pmr::set_default_resource()`.
+
+!!! tip "Reference implementation"
+
+    `docs/mkdocs/docs/examples/custom_string_type.hpp` wraps a private `#!cpp std::string` and satisfies every
+    requirement above -- a good starting point for a custom `StringType`. The unit test
+    `tests/src/unit-alt-string.cpp` contains a more thorough variant, `alt_string`, exercised against a larger part
+    of the API.
+
+    ```cpp
+    --8<-- "examples/custom_string_type.hpp"
+    ```
+
+??? example "Compiling and using it"
+
+    ```cpp
+    --8<-- "examples/custom_string_type.cpp"
+    ```
+
+    Output:
+
+    ```json
+    --8<-- "examples/custom_string_type.output"
+    ```
+
+## `BooleanType`
+
+`boolean_t` is stored **directly** inside `basic_json`, as a member of an anonymous union.
+
+### Always required
+
+- A literal type that is trivially default-constructible, trivially copyable, and trivially destructible; otherwise the
+  union's special member functions are deleted.
+- **Implicitly** convertible from `#!cpp bool` -- an `#!cpp explicit` constructor is not enough, because the
+  `to_json` overload for a custom `BooleanType` is constrained on `#!cpp std::is_convertible` -- and contextually
+  convertible to `#!cpp bool` (here an `#!cpp explicit operator bool` is fine).
+- Comparison operators `==`, `!=`, `<`, `<=`, `>`, `>=` (or `<=>`).
+- Convertible from and to `#!cpp bool` through the serializer, because
+  [`get<bool>()`](../../api/basic_json/get.md) is used internally.
+
+There is little reason to use anything other than `#!cpp bool` here.
+
+### Compatible types
+
+`#!cpp bool` is the only usable choice. Another trivially copyable type that is implicitly convertible to and from
+`#!cpp bool` -- `#!cpp std::uint8_t`, say -- does compile, and JSON booleans still round-trip, but the type then
+serves as both `boolean_t` and an ordinary integer: `basic_json` can no longer be constructed or assigned from a
+`#!cpp std::uint8_t` at all (the boolean and unsigned-integer `to_json` overloads become ambiguous), and
+[`get<std::uint8_t>()`](../../api/basic_json/get.md) on a number throws
+[`type_error.302`](../../home/exceptions.md#jsonexceptiontype_error302) instead of returning the value.
+
+## `NumberIntegerType` and `NumberUnsignedType`
+
+Both types are stored **directly** inside `basic_json`'s union.
+
+### Always required
+
+- `#!cpp std::is_integral` must be satisfied: `NumberIntegerType` must be a **signed** integer type,
+  `NumberUnsignedType` an **unsigned** integer type. Class types are not supported -- among others, the constructors
+  taking integer values are constrained on `#!cpp std::is_integral`.
+- Trivially default-constructible, trivially copyable, and trivially destructible (union member).
+- `#!cpp std::numeric_limits` must be specialized for both types.
+- `NumberUnsignedType` must be able to represent the absolute value of every `NumberIntegerType` value; serialization
+  of negative numbers converts the value to `NumberUnsignedType`. A `#!cpp static_assert` requires it to be at least as
+  wide as `NumberIntegerType`, which is what that amounts to for the standard integer types.
+- Both types must fit into the internal 64-character number buffer used by
+  [`dump`](../../api/basic_json/dump.md), which is the case for all standard integer types.
+- [`std::hash<basic_json>`](../../api/basic_json/std_hash.md) additionally requires `#!cpp std::hash` specializations.
+
+### Notes
+
+The number types influence what the parser accepts: an integer literal that does not round-trip through the chosen type
+is stored as [`number_float_t`](../../api/basic_json/number_float_t.md) instead. Choosing types narrower than 64 bits
+therefore silently changes parse results rather than raising an error. See
+[Number Handling](number_handling.md) for details.
+
+### Compatible types
+
+| Type pair                                                                                    | Support                                                                                                                                                                                          |
+|----------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `#!cpp std::int64_t` / `#!cpp std::uint64_t` (default)                                       | full                                                                                                                                                                                             |
+| `#!cpp std::int32_t` / `#!cpp std::uint32_t`, `#!cpp long long` / `#!cpp unsigned long long` | full; narrower types change which literals the parser can represent                                                                                                                              |
+| any other pair of standard signed/unsigned integer types                                     | full                                                                                                                                                                                             |
+| class types, enumerations                                                                    | not usable; `#!cpp std::is_integral` must hold                                                                                                                                                   |
+| `#!cpp bool`, or a type already used for another member of the union                         | not usable; `#!cpp std::is_integral<bool>` is in fact `#!cpp true`, but the `get_impl_ptr` overloads for `boolean_t`, `number_integer_t`, `number_unsigned_t` and `number_float_t` would collide |
+
+## `NumberFloatType`
+
+`number_float_t` is stored **directly** inside `basic_json`'s union.
+
+### Always required
+
+- Trivially default-constructible, trivially copyable, and trivially destructible (union member).
+- `#!cpp std::numeric_limits` must be specialized; `max_digits10` is used to size the conversion.
+- `#!cpp std::isfinite` must be applicable to the type.
+
+### Required for parsing and serialization
+
+`NumberFloatType` must be one of `#!cpp float`, `#!cpp double`, or `#!cpp long double`:
+
+- The [parser](../parsing/index.md) converts number literals with `#!cpp std::strtof`, `#!cpp std::strtod`, or
+  `#!cpp std::strtold`; the library provides overloads for exactly these three types.
+- [`dump`](../../api/basic_json/dump.md) falls back to `#!cpp std::snprintf` with the `%g` and `%Lg` conversion
+  specifiers, for which the library likewise provides only `#!cpp double` and `#!cpp long double` overloads
+  (`#!cpp float` is promoted to `#!cpp double`).
+
+If `#!cpp std::numeric_limits<NumberFloatType>` describes an IEEE 754 binary32 or binary64 number, `dump` uses the
+Grisu2 algorithm, which produces the shortest representation that round-trips. Otherwise the `snprintf` fallback with
+`max_digits10` digits is used.
+
+### Required for the binary formats
+
+`NumberFloatType` must be `#!cpp float` or `#!cpp double`. The writers for
+[CBOR, MessagePack, UBJSON, BJData, BON8, and BSON](../binary_formats/index.md) map a floating-point value onto an IEEE 754
+binary32 or binary64 field and have no encoding for `#!cpp long double`.
+
+### Compatible types
+
+| Type                     | Support                                                                                                               |
+|--------------------------|-----------------------------------------------------------------------------------------------------------------------|
+| `#!cpp double` (default) | full; short round-trip output through Grisu2                                                                          |
+| `#!cpp float`            | full; short round-trip output through Grisu2                                                                          |
+| `#!cpp long double`      | `dump` and `parse` only; the binary format writers do not compile, as they only handle IEEE 754 binary32 and binary64 |
+| any other type           | not usable                                                                                                            |
+
+## `AllocatorType`
+
+`AllocatorType` is instantiated with **one** argument, for each of `object_t`, `array_t`, `string_t`, `binary_t`,
+`basic_json`, `#!cpp std::pair<const StringType, basic_json>`, and `#!cpp std::pair<StringType, basic_json>`.
+
+`AllocatorType` is not the only allocator a `basic_json` uses. It allocates the JSON values themselves, but most
+temporary storage is allocated with `#!cpp std::allocator`. This includes the parser's stacks and the stacks that
+process deeply nested values without recursion.
+
+### Always required
+
+- The template must be usable with exactly one type argument. The library instantiates `AllocatorType<T>` directly and
+  never uses `#!cpp std::allocator_traits<...>::rebind_alloc`.
+- It must satisfy the [Allocator](https://en.cppreference.com/w/cpp/named_req/Allocator) named requirement so that
+  `#!cpp std::allocator_traits` can be used with it.
+- It must be **default-constructible and stateless**. Objects are allocated with a default-constructed allocator and
+  deallocated with a *different* default-constructed allocator, and
+  [`get_allocator()`](../../api/basic_json/get_allocator.md) returns a default-constructed instance. Allocators
+  carrying state are not supported, so there is no way to tell a `basic_json` where to allocate from; see the note
+  under [`StringType`](#stringtype) for what that means in practice. A stateful allocator is **not diagnosed**: it
+  compiles and silently ignores the state.
+- It must support **incomplete types**: `AllocatorType<basic_json>` is instantiated inside the definition of
+  `basic_json` itself.
+- `#!cpp std::allocator_traits<AllocatorType<basic_json>>::pointer` becomes
+  [`basic_json::pointer`](../../api/basic_json/index.md#container-types), and iterators are constructed from raw
+  `#!cpp basic_json*` values. The `pointer` type must therefore be a plain pointer; fancy pointers are not supported.
+
+### Compatible types
+
+| Type                                                              | Support                                |
+|-------------------------------------------------------------------|----------------------------------------|
+| `#!cpp std::allocator` (default)                                  | full                                   |
+| a custom stateless allocator template                             | full                                   |
+| stateful allocators, e.g. `#!cpp std::pmr::polymorphic_allocator` | not usable; see the requirements above |
+
+## `JSONSerializer`
+
+`JSONSerializer` is instantiated as `JSONSerializer<T, void>` and defaults to
+[`adl_serializer`](../../api/adl_serializer/index.md).
+
+### Always required
+
+- The template must accept **two** type arguments. It does not have to give the second one a default -- `basic_json`
+  declares the parameter as `#!cpp template<typename T, typename SFINAE = void> class JSONSerializer`, so uses such as
+  `#!cpp JSONSerializer<T>` inside the library supply `#!cpp void` themselves. The second parameter exists so that
+  partial specializations can be constrained by SFINAE.
+- For every type `T` that is converted **to** a JSON value, a static member function
+  `#!cpp static void to_json(basic_json&, T)` must exist.
+- For every type `T` that is converted **from** a JSON value, either
+  `#!cpp static void from_json(const basic_json&, T&)` or `#!cpp static T from_json(const basic_json&)` must exist.
+  The latter form is required for types that are not default-constructible; see
+  [Arbitrary Types Conversions](../arbitrary_types.md).
+- To support the [converting constructor](../../api/basic_json/basic_json.md) between different `basic_json`
+  specializations, `to_json` must be available for `boolean_t`, `number_integer_t`, `number_unsigned_t`,
+  `number_float_t`, `string_t`, `object_t`, `array_t`, and `binary_t` of the *source* specialization.
+
+### Compatible types
+
+| Type                                                                      | Support                                                           |
+|---------------------------------------------------------------------------|-------------------------------------------------------------------|
+| [`nlohmann::adl_serializer`](../../api/adl_serializer/index.md) (default) | full                                                              |
+| a class template deriving from `adl_serializer`                           | full; the usual way to change behavior while keeping the defaults |
+| an unrelated template with the same interface                             | full, but it has to handle every type the library converts        |
+
+## `BinaryType`
+
+`BinaryType` is not a JSON type; it is used for the byte strings of the
+[binary formats](../binary_formats/index.md). It is wrapped as
+
+```cpp
+using binary_t = nlohmann::byte_container_with_subtype<BinaryType>;
+```
+
+### Always required
+
+- A non-`final` class type -- [`byte_container_with_subtype`](../../api/byte_container_with_subtype/index.md) derives
+  from it publicly.
+- A member type `value_type` that is **exactly one byte** wide (e.g., `#!cpp std::uint8_t`, `#!cpp char`, or
+  `#!cpp std::byte`). Readers and writers reinterpret the container's storage as raw bytes, so a wider `value_type` is
+  rejected with a `#!cpp static_assert`.
+- Contiguous storage: the binary readers `#!cpp std::memcpy` into `#!cpp &binary[n]`, the writers `reinterpret_cast`
+  `data()`. `#!cpp data() + n` would do for the readers too, but they share one helper with
+  [`StringType`](#stringtype), whose non-`#!cpp const` `data()` is C++17 and later only.
+- Default-constructible, copy-constructible, and move-constructible.
+- Member functions `size()`, `empty()`, `data()`, `resize()`, `operator[]`, `back()`, `begin()`, `end()`, `cbegin()`,
+  and `cend()` with random-access iterators, and `insert(pos, first, last)`, which the CBOR reader uses to join the
+  chunks of an indefinite-length byte string. `push_back()` is **not** required.
+- Comparison operators: `==` is used by
+  [`byte_container_with_subtype`](../../api/byte_container_with_subtype/index.md), the relational operators by
+  [`basic_json`'s comparison operators](../../api/basic_json/operator_le.md).
+
+### Required for individual functions
+
+- `clear()`, for [`basic_json::clear()`](../../api/basic_json/clear.md).
+
+`max_size()`, `at()`, `reserve()`, `erase()`, `pop_back()`, and `emplace_back()` are **not** used at all.
+
+See [`binary_t`](../../api/basic_json/binary_t.md) for how a non-default `BinaryType` changes the meaning of assigning
+such a container to a `basic_json` value.
+
+!!! tip "Reference implementation"
+
+    `docs/mkdocs/docs/examples/custom_binary_type.hpp` wraps a private `#!cpp std::vector<std::uint8_t>` and satisfies
+    every requirement above -- a good starting point for a custom `BinaryType`.
+
+    ```cpp
+    --8<-- "examples/custom_binary_type.hpp"
+    ```
+
+??? example "Compiling and using it"
+
+    ```cpp
+    --8<-- "examples/custom_binary_type.cpp"
+    ```
+
+    Output:
+
+    ```json
+    --8<-- "examples/custom_binary_type.output"
+    ```
+
+### Compatible containers
+
+| Container                                                                                   | Notes                                                                     |
+|---------------------------------------------------------------------------------------------|---------------------------------------------------------------------------|
+| `#!cpp std::vector<std::uint8_t>` (default)                                                 |                                                                           |
+| `#!cpp std::vector<char>`, `#!cpp std::vector<std::byte>`                                   | `dump()` writes the bytes as 0..255 whichever is used                     |
+| `boost::container::vector<std::uint8_t>`, `boost::container::small_vector<std::uint8_t, N>` |                                                                           |
+| `absl::InlinedVector<std::uint8_t, N>`                                                      | usable here, unlike as an `ArrayType`, because the value type is complete |
+| `eastl::vector<std::uint8_t>`                                                               | usable here, unlike as an `ArrayType`, because `max_size()` is not needed |
+| `folly::fbvector<std::uint8_t>`                                                             | requires C++20, see the note above                                        |
+
+### Containers that cannot be used
+
+| Container                                            | Reason                                                                                                                                                                                             |
+|------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `QByteArray`                                         | no `empty()` (it spells that `isEmpty()`); its `insert` takes an index rather than an iterator; and it converts to `string_t`, which makes `to_json` ambiguous between a string and a binary value |
+| `#!cpp std::string`                                  | `binary_t::container_type` and `string_t` would be the same type, so the two [`swap`](../../api/basic_json/swap.md) overloads collide and `basic_json` cannot be instantiated at all               |
+| `#!cpp std::deque<std::uint8_t>`                     | storage is not contiguous, so there is no `data()`                                                                                                                                                 |
+| containers whose `value_type` is wider than one byte | see above -- accepted by the compiler, wrong at runtime                                                                                                                                            |
+
+## `CustomBaseClass`
+
+`CustomBaseClass` is an extension point: unless it is `#!cpp void` (the default, which selects the empty
+`nlohmann::json_default_base`), `basic_json` publicly derives from it.
+
+### Always required
+
+- A non-`final`, default-constructible class type.
+- `basic_json` is copy-/move-constructible and copy-/move-assignable only if `CustomBaseClass` is.
+
+### Notes
+
+`basic_json` is documented to be a
+[StandardLayoutType](https://en.cppreference.com/w/cpp/named_req/StandardLayoutType). Because `basic_json` has
+non-static data members of its own, a `CustomBaseClass` with non-static data members forfeits this guarantee.
+
+Note the namespace of `CustomBaseClass` becomes an associated namespace of `basic_json` for the purpose of
+argument-dependent lookup.
+
+See [`json_base_class_t`](../../api/basic_json/json_base_class_t.md) for an example.
+
+### Compatible types
+
+| Type                                         | Support                                                                    |
+|----------------------------------------------|----------------------------------------------------------------------------|
+| `#!cpp void` (default)                       | an empty base class is used; no effect on `basic_json`                     |
+| any default-constructible, non-`final` class | full; see [`json_base_class_t`](../../api/basic_json/json_base_class_t.md) |
+
+## Cross-specialization conversions
+
+Converting a value from one `basic_json` specialization into another (see the
+[converting constructor](../../api/basic_json/basic_json.md)) imposes two additional requirements that are not
+diagnosed at compile time. With assertions enabled they abort on the `#!cpp JSON_ASSERT` at the end of the converting
+constructor; under `#!cpp NDEBUG` they fail **silently** at runtime:
+
+- The target `string_t` must be directly constructible from the source `string_t`. Otherwise the string is converted to
+  an array of character codes.
+- The target `object_t::key_type` must be directly constructible from the source object's key type. Otherwise the
+  object is converted to an array of key/value pairs.
+
+See [issue #3425](https://github.com/nlohmann/json/issues/3425), [`string_t`](../../api/basic_json/string_t.md), and
+[`object_t`](../../api/basic_json/object_t.md).
+
+## See also
+
+- [Types](index.md) -- overview of how JSON values are stored
+- [Number Handling](number_handling.md) -- how the number types affect parsing and serialization
+- [Object Order](../object_order.md) -- using an insertion-ordered `ObjectType`
+- [`basic_json`](../../api/basic_json/index.md) -- API documentation of the class template

docs/mkdocs/docs/home/architecture.md

@@ -1,34 +1,125 @@
 # Architecture
 
-!!! info
-
-    This page is still under construction. Its goal is to provide a high-level overview of the library's architecture.
-    This should help new contributors to get an idea of the used concepts and where to make changes.
+This page gives a high-level overview of the library's architecture. It should help new contributors to get an idea of
+the used concepts and where to make changes.
 
 ## Overview
 
-The main structure is class [nlohmann::basic_json](../api/basic_json/index.md).
+The library is built around a single class template, [`nlohmann::basic_json`](../api/basic_json/index.md). A
+`basic_json` value is a node in a tree of JSON values. All other components either create such a tree from an input
+(parsing), write a tree to an output (serialization), or give access to it (iterators, JSON Pointer, conversions).
 
-- public API
-- container interface
-- iterators
+```mermaid
+flowchart LR
+    input[/"input<br>(string, stream,<br>iterator range, file)"/]
+    ia["input adapter"]
+    lexer["lexer"]
+    parser["parser"]
+    breader["binary_reader"]
+    sax["SAX interface"]
+    value[("basic_json<br>value tree")]
+    serializer["serializer"]
+    bwriter["binary_writer"]
+    oa["output adapter"]
+    output[/"output<br>(string, stream,<br>vector)"/]
 
-## Template specializations
+    input --> ia
+    ia --> lexer --> parser --> sax
+    ia --> breader --> sax
+    sax --> value
+    value --> serializer --> oa
+    value --> bwriter --> oa
+    oa --> output
+```
 
-- describe template parameters of `basic_json`
-- [`json`](../api/json.md)
-- [`ordered_json`](../api/ordered_json.md) via [`ordered_map`](../api/ordered_map/index.md)
+- **JSON text** is read by an [input adapter](#input-adapters), tokenized by the lexer, and turned into SAX events by
+  the parser.
+- **Binary formats** (BJData, BSON, CBOR, MessagePack, UBJSON) are read by an input adapter and turned into the same SAX
+  events by the `binary_reader`.
+- A [SAX consumer](#sax-interface) receives the events. The one used by [`parse`](../api/basic_json/parse.md) builds a
+  `basic_json` value tree.
+- The `serializer` (JSON text) or the `binary_writer` (binary formats) writes a value tree to an
+  [output adapter](#output-adapters).
+
+## Source layout
+
+The public headers are in [`include/nlohmann`](https://github.com/nlohmann/json/tree/develop/include/nlohmann):
+
+- [`json.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/json.hpp) defines class [`basic_json`](../api/basic_json/index.md).
+- [`json_fwd.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/json_fwd.hpp) contains forward declarations.
+- [`adl_serializer.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/adl_serializer.hpp), [`byte_container_with_subtype.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/byte_container_with_subtype.hpp), and [`ordered_map.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/ordered_map.hpp) define
+  [`adl_serializer`](../api/adl_serializer/index.md),
+  [`byte_container_with_subtype`](../api/byte_container_with_subtype/index.md), and
+  [`ordered_map`](../api/ordered_map/index.md).
+
+Everything else lives in [`detail/`](https://github.com/nlohmann/json/tree/develop/include/nlohmann/detail) and namespace `nlohmann::detail`, which is not part of the public API. Paths
+below are relative to `include/nlohmann`.
+
+| Component | Location |
+|-----------|----------|
+| Value type enumeration | [`detail/value_t.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/value_t.hpp) |
+| Input adapters | [`detail/input/input_adapters.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/input/input_adapters.hpp) |
+| Lexer | [`detail/input/lexer.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/input/lexer.hpp), [`detail/input/number_parse.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/input/number_parse.hpp), [`detail/input/string_scan.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/input/string_scan.hpp) |
+| Parser | [`detail/input/parser.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/input/parser.hpp) |
+| SAX interface and DOM builders | [`detail/input/json_sax.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/input/json_sax.hpp) |
+| Binary format readers | [`detail/input/binary_reader.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/input/binary_reader.hpp) |
+| JSON serializer | [`detail/output/serializer.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/output/serializer.hpp), [`detail/conversions/to_chars.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/conversions/to_chars.hpp) |
+| Binary format writers | [`detail/output/binary_writer.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/output/binary_writer.hpp) |
+| Output adapters | [`detail/output/output_adapters.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/output/output_adapters.hpp) |
+| Iterators | [`detail/iterators/`](https://github.com/nlohmann/json/tree/develop/include/nlohmann/detail/iterators) |
+| Conversions from/to arbitrary types | [`detail/conversions/from_json.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/conversions/from_json.hpp), [`detail/conversions/to_json.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/conversions/to_json.hpp) |
+| JSON Pointer | [`detail/json_pointer.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/json_pointer.hpp) |
+| Exceptions | [`detail/exceptions.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/exceptions.hpp) |
+| Type traits and C++ feature backports | [`detail/meta/`](https://github.com/nlohmann/json/tree/develop/include/nlohmann/detail/meta) |
+| Macros | [`detail/macro_scope.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/macro_scope.hpp), [`detail/macro_unscope.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/macro_unscope.hpp), [`detail/abi_macros.hpp`](https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/abi_macros.hpp) |
+
+The single-header version [`single_include/nlohmann/json.hpp`](https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp)
+is generated from these files with `make amalgamate` and must not be edited by hand.
+
+## Template parameters
+
+[`basic_json`](../api/basic_json/index.md) is parameterized by the types it uses to store values and to convert from and to other types:
+
+| Template parameter   | Default                     | Used for                                                          |
+|----------------------|-----------------------------|-------------------------------------------------------------------|
+| `ObjectType`         | `std::map`                  | objects, see [`object_t`](../api/basic_json/object_t.md)          |
+| `ArrayType`          | `std::vector`               | arrays, see [`array_t`](../api/basic_json/array_t.md)             |
+| `StringType`         | `std::string`               | strings and object keys, see [`string_t`](../api/basic_json/string_t.md) |
+| `BooleanType`        | `bool`                      | Booleans, see [`boolean_t`](../api/basic_json/boolean_t.md)       |
+| `NumberIntegerType`  | `std::int64_t`              | signed integers, see [`number_integer_t`](../api/basic_json/number_integer_t.md) |
+| `NumberUnsignedType` | `std::uint64_t`             | unsigned integers, see [`number_unsigned_t`](../api/basic_json/number_unsigned_t.md) |
+| `NumberFloatType`    | `double`                    | floating-point numbers, see [`number_float_t`](../api/basic_json/number_float_t.md) |
+| `AllocatorType`      | `std::allocator`            | allocating objects, arrays, strings, and binary values            |
+| `JSONSerializer`     | `adl_serializer`            | conversions from/to other types, see [`adl_serializer`](../api/adl_serializer/index.md) |
+| `BinaryType`         | `std::vector<std::uint8_t>` | binary values, see [`binary_t`](../api/basic_json/binary_t.md)  |
+| `CustomBaseClass`    | `void`                      | an optional base class, see [`json_base_class_t`](../api/basic_json/json_base_class_t.md) |
+
+The library provides two specializations:
+
+- [`json`](../api/json.md) uses all default template arguments.
+- [`ordered_json`](../api/ordered_json.md) uses [`ordered_map`](../api/ordered_map/index.md) as `ObjectType` to keep the
+  insertion order of object keys.
+
+The requirements on the template arguments are listed in
+[Template Parameter Requirements](../features/types/template_parameters.md).
 
 ## Value storage
 
-Values are stored as a tagged union of [value_t](../api/basic_json/value_t.md) and json_value.
+Each [`basic_json`](../api/basic_json/index.md) value stores its content as a tagged union: an enumeration [`value_t`](../api/basic_json/value_t.md)
+names the type of the value, and a union `json_value` holds the value itself. Both are members of the nested struct
+`data`, which is the only data member `m_data` of `basic_json`:
 
 ```cpp
-/// the type of the current element
-value_t m_type = value_t::null;
+struct data
+{
+    /// the type of the current element
+    value_t m_type = value_t::null;
 
-/// the value of the current element
-json_value m_value = {};
+    /// the value of the current element
+    json_value m_value = {};
+};
+
+data m_data = {};
 ```
 
 with
@@ -68,42 +159,83 @@ union json_value {
 };
 ```
 
-## Parsing inputs (deserialization)
+Objects, arrays, strings, and binary values are allocated on the heap with `AllocatorType`, and the union only stores a
+pointer to them. This keeps a `basic_json` value small: one pointer-sized union and one byte for the type. The class
+maintains the invariant that the pointer matching `m_type` is never null; `assert_invariant()` checks it with
+[runtime assertions](../features/assertions.md).
 
-Input is read via **input adapters** that abstract a source with a common interface:
+## Input adapters
+
+Input is read via **input adapters** that abstract a source. Every input adapter provides this interface:
 
 ```cpp
-/// read a single character
-std::char_traits<char>::int_type get_character() noexcept;
+/// the type of the characters in the input
+using char_type = ...;
 
-/// read multiple characters to a destination buffer and
-/// returns the number of characters successfully read
+/// read a single character; returns std::char_traits<char_type>::eof() at the end of the input
+typename std::char_traits<char_type>::int_type get_character();
+
+/// read up to count * sizeof(T) bytes into dest and return the number of bytes read
+/// (used by the binary readers)
 template<class T>
 std::size_t get_elements(T* dest, std::size_t count = 1);
 ```
 
-List examples of input adapters.
+The lexer detects two optional extensions at compile time. Only `iterator_input_adapter` provides them, and only for
+random-access input of single-byte characters:
 
-## SAX Interface
+- `supports_seek`, `get_consumed_count()`, and `copy_consumed_range()` let the lexer reconstruct already consumed input
+  for error messages instead of copying every character it reads.
+- `supports_bulk_scan`, `bulk_data()`, `bulk_remaining()`, and `bulk_skip()` let the lexer scan strings directly in
+  contiguous memory, several bytes at a time.
 
-TODO
+The function `input_adapter` picks the right adapter for the argument passed to `parse`, `accept`, `sax_parse`, or the
+`from_*` functions:
 
-## Writing outputs (serialization)
+- `iterator_input_adapter` reads from an iterator range, which also covers strings, containers, and pointers.
+- `wide_string_input_adapter` reads from ranges of `wchar_t`, `char16_t`, or `char32_t` and converts them to UTF-8.
+  It cannot be used for binary formats; its `get_elements()` throws.
+- `input_stream_adapter` reads from a `std::istream`.
+- `file_input_adapter` reads from a `std::FILE*`.
+
+## SAX interface
+
+The parser does not build values itself. It reports what it reads as events to a [SAX](../features/parsing/sax_interface.md)
+consumer, which implements the interface [`json_sax`](../api/json_sax/index.md): `null`, `boolean`, `number_integer`,
+`number_unsigned`, `number_float`, `string`, `binary`, `start_object`, `key`, `end_object`, `start_array`, `end_array`,
+and `parse_error`.
+
+The library comes with two consumers in `detail/input/json_sax.hpp`:
+
+- `json_sax_dom_parser` builds a [`basic_json`](../api/basic_json/index.md) value tree. [`parse`](../api/basic_json/parse.md) uses it.
+- `json_sax_dom_callback_parser` does the same, but calls a [parser callback](../features/parsing/parser_callbacks.md)
+  for each event, which can skip values. `parse` uses it when a callback is given.
+
+The `binary_reader` emits the same events for binary formats, so [`sax_parse`](../api/basic_json/sax_parse.md) works
+with a user-defined consumer for JSON and for all binary formats alike.
+
+## Output adapters
 
 Output is written via **output adapters**:
 
 ```cpp
-template<typename T>
 void write_character(CharType c);
 
-template<typename CharType>
 void write_characters(const CharType* s, std::size_t length);
 ```
 
-List examples of output adapters.
+The `serializer` (used by [`dump`](../api/basic_json/dump.md) and [`operator<<`](../api/operator_ltlt.md)) and the
+`binary_writer` (used by the `to_*` functions) write to one of these adapters:
+
+- `output_vector_adapter` appends to a `std::vector`.
+- `output_stream_adapter` writes to a `std::ostream`.
+- `output_string_adapter` appends to a string.
 
 ## Value conversion
 
+Values are converted from and to other types with the `JSONSerializer` template parameter. The default,
+[`adl_serializer`](../api/adl_serializer/index.md), calls the free functions
+
 ```cpp
 template<class T>
 void to_json(basic_json& j, const T& t);
@@ -112,13 +244,23 @@ template<class T>
 void from_json(const basic_json& j, T& t);
 ```
 
+found by argument-dependent lookup. The library defines them for standard types in `detail/conversions`; users add them
+for their own types, see [Arbitrary Type Conversions](../features/arbitrary_types.md). The
+[serialization macros](../features/macros.md) generate these functions.
+
 ## Additional features
 
-- JSON Pointers
-- Binary formats
-- Custom base class
-- Conversion macros
+- [JSON Pointer](../features/json_pointer.md) (class `json_pointer`) addresses values inside a tree. It is also the
+  basis of [JSON Patch](../features/json_patch.md).
+- [Binary formats](../features/binary_formats/index.md) are read by `binary_reader` and written by `binary_writer`.
+- A [custom base class](../api/basic_json/json_base_class_t.md) can add members to every [`basic_json`](../api/basic_json/index.md) value.
+- [Serialization macros](../features/macros.md) generate `to_json` and `from_json` functions for user-defined types.
 
 ## Details namespace
 
-- C++ feature backports
+Namespace `nlohmann::detail` contains all implementation details. It is not part of the public API and may change in any
+release. Besides the components above, it contains:
+
+- type traits to detect the capabilities of user-defined types (`detail/meta/type_traits.hpp`),
+- backports of C++14/17 features to C++11 (`detail/meta/cpp_future.hpp`), and
+- helpers such as `string_concat` and `string_escape`.

docs/mkdocs/docs/home/design_goals.md

@@ -6,7 +6,7 @@ There are myriads of [JSON](https://json.org) libraries out there, and each may
 
 - **Trivial integration**. Our whole code consists of a single header file [`json.hpp`](https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp). That's it. No library, no subproject, no dependencies, no complex build system. The class is written in vanilla C++11. All in all, everything should require no adjustment of your compiler flags or project settings.
 
-- **Serious testing**. Our class is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](http://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [Core Infrastructure Initiative (CII) best practices](https://bestpractices.coreinfrastructure.org/projects/289).
+- **Serious testing**. Our class is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](http://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [OpenSSF Best Practices](https://www.bestpractices.dev/projects/289).
 
 Other aspects were not so important to us:
 

docs/mkdocs/docs/home/exceptions.md

@@ -340,7 +340,8 @@ An unexpected byte was read in a [binary format](../features/binary_formats/inde
 ### json.exception.parse_error.113
 
 A string could not be read from a [binary format](../features/binary_formats/index.md): either a value that is not a
-string was read where one was required (for instance as a map key), or the string's length specification is invalid.
+string was read where one was required (for instance as a map key), the string's length specification is invalid, or
+the string's bytes are not valid UTF-8.
 
 !!! failure "Example messages"
 
@@ -356,6 +357,9 @@ string was read where one was required (for instance as a map key), or the strin
     ```
     [json.exception.parse_error.113] parse error at byte 3: syntax error while parsing BJData string: string length must not be negative
     ```
+    ```
+    [json.exception.parse_error.113] parse error at byte 3: syntax error while parsing CBOR string: invalid string: ill-formed UTF-8 byte
+    ```
 
 ### json.exception.parse_error.114
 
@@ -928,19 +932,25 @@ A JSON Patch `add` operation cannot be applied because the target location's par
 
 ### json.exception.out_of_range.412
 
-BSON stores the length of documents, arrays, strings, and binary values in a signed 32-bit integer. This exception is thrown when a value is too large to be described by such a length field.
+BSON stores the length of documents, arrays, strings, and binary values in a signed 32-bit integer, and MessagePack
+stores the length of strings, binary values, arrays, and objects in at most an unsigned 32-bit integer. This exception
+is thrown when a value is too large to be described by such a length field.
 
-!!! failure "Example message"
+!!! failure "Example messages"
 
     ```
     BSON length 2147483661 exceeds maximum of 2147483647
     ```
+    ```
+    MessagePack length 4294967296 exceeds maximum of 4294967295
+    ```
 
 !!! note
 
-    This exception was added in version 3.13.0. Before that, the length was silently truncated, and
+    This exception was added in version 3.13.0. Before that, the BSON length was silently truncated, and
     [`to_bson`](../api/basic_json/to_bson.md) produced documents with negative length prefixes that
-    [`from_bson`](../api/basic_json/from_bson.md) rejected.
+    [`from_bson`](../api/basic_json/from_bson.md) rejected; [`to_msgpack`](../api/basic_json/to_msgpack.md) wrote such
+    a value without any length, producing output that could not be read back.
 
 ### json.exception.out_of_range.413
 
@@ -970,6 +980,21 @@ A JSON Patch `move` operation's `"from"` location is a proper prefix of its `"pa
 
     This exception was added in version 3.13.0. Before that, this situation could succeed with a corrupted result: for an array target, removing the "from" element before the "add" step shifted subsequent indices, so "path" silently re-resolved to a different element than intended.
 
+### json.exception.out_of_range.415
+
+MessagePack's ext type and BSON's binary subtype are each stored in a single byte. This exception is thrown when serializing a
+[`byte_container_with_subtype`](../api/byte_container_with_subtype/index.md) whose subtype exceeds 255.
+
+!!! failure "Example message"
+
+    ```
+    [json.exception.out_of_range.415] subtype 70000 is too large for the MessagePack ext type (max 255)
+    ```
+
+!!! note
+
+    This exception was added in version 3.13.0. Before that, subtypes above 255 were silently truncated modulo 256 instead of raising an error.
+
 ## Further exceptions
 
 This exception is thrown in case of errors that cannot be classified with the

docs/mkdocs/docs/home/faq.md

@@ -90,6 +90,54 @@ The library supports **Unicode input** as follows:
 In most cases, the parser is right to complain, because the input is not UTF-8 encoded. This is especially true for Microsoft Windows, where Latin-1 or ISO 8859-1 is often the standard encoding.
 
 
+### NUL bytes in the input
+
+!!! question "Questions"
+
+    - Why does `json::parse()` silently ignore part of my input?
+    - Why does a `std::string`/buffer with extra data after the JSON text parse without error, while a similar-looking string with extra text does not?
+
+A `'\0'` (NUL) byte anywhere in the input is treated the same as the real end of the input, rather than as an ordinary (and, outside of a string, invalid) byte. Everything from that byte onward is silently ignored, without a parse error — including further, otherwise well-formed JSON:
+
+```cpp
+json::parse(std::string("123") + '\0');          // == 123, no error
+json::parse(std::string("123") + '\0' + "true"); // == 123, the "true" is silently ignored too
+```
+
+This is different from any other unexpected trailing byte, which *does* raise [`parse_error.101`](../home/exceptions.md#jsonexceptionparse_error101):
+
+```cpp
+json::parse("123x"); // throws parse_error.101: unexpected additional data
+```
+
+This falls out of the same convention used when no explicit input length is given at all: `json::parse(const char*)` already stops at the first NUL byte via `strlen()`, since a bare pointer has no length of its own. The library applies that same NUL-terminated-C-string convention uniformly, rather than only when a length is genuinely unavailable — so a `std::string`, iterator range, or container whose content happens to include a NUL byte is affected the same way a raw `const char*` would be.
+
+If your input may contain a trailing or embedded NUL that is **not** meant to signal the end of the JSON text — for instance, a fixed-size, zero-padded buffer — trim it yourself before calling `parse()`, since the library will otherwise silently stop there instead of raising an error:
+
+```cpp
+s.resize(s.find('\0')); // drop everything from the first NUL onward, if any
+json::parse(s);
+```
+
+**Opt-in strict handling (since version 3.13.0)**
+
+Manually trimming every input is easy to forget. If you define [`JSON_STRICT_NUL_HANDLING`](../api/macros/json_strict_nul_handling.md) to `1` before including the library, a `'\0'` byte is instead rejected like any other unexpected byte and raises `parse_error.101`, instead of being treated as end of input:
+
+```cpp
+#define JSON_STRICT_NUL_HANDLING 1
+#include <nlohmann/json.hpp>
+
+json::parse(std::string("123") + '\0'); // throws parse_error.101 instead of silently returning 123
+```
+
+This macro defaults to `0` (disabled, preserving the behavior described above) to avoid breaking existing code that may depend on it, even unknowingly; it is planned to become the default in version 4.0.0. See [its documentation](../api/macros/json_strict_nul_handling.md) for details, including how it also affects `char` arrays such as string literals.
+
+Note that this is unrelated to an *unescaped* NUL byte occurring **inside** a quoted JSON string, which is a different, already-invalid case and is correctly rejected either way:
+
+```cpp
+json::parse(std::string("\"") + '\0' + "\""); // throws parse_error.101: control character U+0000 (NUL) must be escaped to \u0000
+```
+
 ### Wide string handling
 
 !!! question

docs/mkdocs/docs/integration/cmake.md

@@ -198,6 +198,11 @@ Use the non-amalgamated version of the library. This option is `ON` by default.
 
 Treat the library headers like system headers (i.e., adding `SYSTEM` to the [`target_include_directories`](https://cmake.org/cmake/help/latest/command/target_include_directories.html) call) to check for this library by tools like Clang-Tidy. This option is `OFF` by default.
 
+### `JSON_StrictNulHandling`
+
+Reject a `'\0'` (NUL) byte in the input instead of treating it as end of input, by defining the macro
+[`JSON_STRICT_NUL_HANDLING`](../api/macros/json_strict_nul_handling.md). This option is `OFF` by default.
+
 ### `JSON_Valgrind`
 
 Execute the test suite with [Valgrind](https://valgrind.org). This option is `OFF` by default. Depends on `JSON_BuildTests`.

docs/mkdocs/docs/integration/migration_guide.md

@@ -176,6 +176,12 @@ You can prepare existing code by already defining
 conversions with calls to [`get`](../api/basic_json/get.md), [`get_to`](../api/basic_json/get_to.md),
 [`get_ref`](../api/basic_json/get_ref.md), or [`get_ptr`](../api/basic_json/get_ptr.md).
 
+!!! tip "Automatic migration"
+
+    The community-maintained clang-tidy check `modernize-nlohmann-json-explicit-conversions` rewrites most implicit
+    conversions into calls to [`get`](../api/basic_json/get.md). It is not part of clang-tidy itself; see
+    [discussion #4610](https://github.com/nlohmann/json/discussions/4610) for how to build and use it.
+
 === "Deprecated"
 
       ```cpp

docs/mkdocs/includes/glossary.md

@@ -5,6 +5,7 @@
 *[ASCII]: American Standard Code for Information Interchange
 *[BDFL]: Benevolent Dictator for Life
 *[BJData]: Binary JData
+*[BON8]: Binary Object Notation 8
 *[BSON]: Binary JSON
 *[CBOR]: Concise Binary Object Representation
 *[CC0]: Creative Commons Zero

docs/mkdocs/mkdocs.yml

@@ -64,6 +64,7 @@ nav:
       - Binary Formats:
           - features/binary_formats/index.md
           - features/binary_formats/bjdata.md
+          - features/binary_formats/bon8.md
           - features/binary_formats/bson.md
           - features/binary_formats/cbor.md
           - features/binary_formats/messagepack.md
@@ -99,6 +100,7 @@ nav:
       - Types:
           - features/types/index.md
           - features/types/number_handling.md
+          - features/types/template_parameters.md
   - Integration:
       - integration/index.md
       - integration/migration_guide.md
@@ -143,6 +145,7 @@ nav:
           - 'flatten': api/basic_json/flatten.md
           - 'format_as': api/basic_json/format_as.md
           - 'from_bjdata': api/basic_json/from_bjdata.md
+          - 'from_bon8': api/basic_json/from_bon8.md
           - 'from_bson': api/basic_json/from_bson.md
           - 'from_cbor': api/basic_json/from_cbor.md
           - 'from_msgpack': api/basic_json/from_msgpack.md
@@ -216,6 +219,7 @@ nav:
           - 'swap': api/basic_json/swap.md
           - 'std::swap<basic_json>': api/basic_json/std_swap.md
           - 'to_bjdata': api/basic_json/to_bjdata.md
+          - 'to_bon8': api/basic_json/to_bon8.md
           - 'to_bson': api/basic_json/to_bson.md
           - 'to_cbor': api/basic_json/to_cbor.md
           - 'to_msgpack': api/basic_json/to_msgpack.md
@@ -320,8 +324,11 @@ nav:
           - 'JSON_HAS_THREE_WAY_COMPARISON': api/macros/json_has_three_way_comparison.md
           - 'JSON_NOEXCEPTION': api/macros/json_noexception.md
           - 'JSON_NO_IO': api/macros/json_no_io.md
+          - 'JSON_NO_THREAD_LOCAL': api/macros/json_no_thread_local.md
+          - 'JSON_PRECISE_STREAM_POSITION': api/macros/json_precise_stream_position.md
           - 'JSON_SKIP_LIBRARY_VERSION_CHECK': api/macros/json_skip_library_version_check.md
           - 'JSON_SKIP_UNSUPPORTED_COMPILER_CHECK': api/macros/json_skip_unsupported_compiler_check.md
+          - 'JSON_STRICT_NUL_HANDLING': api/macros/json_strict_nul_handling.md
           - 'JSON_USE_GLOBAL_UDLS': api/macros/json_use_global_udls.md
           - 'JSON_USE_IMPLICIT_CONVERSIONS': api/macros/json_use_implicit_conversions.md
           - 'JSON_USE_LEGACY_DISCARDED_VALUE_COMPARISON': api/macros/json_use_legacy_discarded_value_comparison.md
@@ -343,7 +350,9 @@ nav:
       - community/contribution_guidelines.md
       - community/quality_assurance.md
       - community/governance.md
+      - community/roadmap.md
       - community/security_policy.md
+      - community/assurance_case.md
 
 # Extras
 extra:
@@ -435,7 +444,7 @@ plugins:
       markdown_description: >
         JSON for Modern C++ is a C++11 header-only library implementing a JSON
         value type with an STL-like API, JSON Pointer/Patch, CBOR/MessagePack/
-        BSON/UBJSON/BJData binary format support, and a SAX-style parser interface.
+        BSON/UBJSON/BJData/BON8 binary format support, and a SAX-style parser interface.
       sections:
         Home:
           - index.md

docs/mkdocs/requirements.txt

@@ -1,7 +1,7 @@
 wheel==0.48.0
 
 mkdocs==1.6.1                                       # documentation framework
-mkdocs-git-revision-date-localized-plugin==1.5.4    # plugin "git-revision-date-localized"
+mkdocs-git-revision-date-localized-plugin==1.6.0    # plugin "git-revision-date-localized"
 mkdocs-material==9.7.7                             # theme for mkdocs
 mkdocs-material-extensions==1.3.1                   # extensions
 mkdocs-minify-plugin==0.8.0                         # plugin "minify"