deploy: e9c3985f0a

features/arbitrary_types.md

@@ -180,6 +180,49 @@ For _derived_ classes and structs, use the following macros
     }
     ```
 
+!!! warning "Overriding conversions for natively-supported types"
+
+    The library already provides built-in `to_json`/`from_json` conversions for STL containers such as
+    `std::vector`, `std::array`, and `std::map`. Defining your own free-function `to_json`/`from_json` overload
+    for one of these container types directly (instead of for your own type) can conflict with the built-in
+    overload during overload resolution, producing compiler errors ("no matching overloaded function",
+    "call is ambiguous") that vary by compiler and library version. If you need different conversion behavior
+    for a container type the library already handles, wrap it in your own type (or use `adl_serializer`
+    specialization, as shown [above](#how-do-i-convert-third-party-types) for `boost::optional`) instead of
+    trying to re-specialize `to_json`/`from_json` for the container type itself.
+
+!!! warning "Raw C-style arrays"
+
+    Members declared as raw C-style arrays (e.g., `char buf[1024]`) do not round-trip safely through
+    `NLOHMANN_DEFINE_TYPE_*` macros or the default (de)serializers: `to_json` serializes any `char` array as a
+    JSON *string* (matching the `std::string`-constructible overload), but the `from_json` overload for
+    fixed-size arrays expects a JSON *array* and iterates it element-wise, which fails with a `type_error` when
+    given a string. Use `std::string`, `std::array<char, N>`, or a manually written `to_json`/`from_json` pair
+    for such members instead.
+
+!!! note "Macros and `nlohmann::ordered_json`"
+
+    The `NLOHMANN_DEFINE_TYPE_*`/`NLOHMANN_DEFINE_DERIVED_TYPE_*` macros are generic over any `basic_json`
+    specialization, including `nlohmann::ordered_json`. Simply use `ordered_json` as the target type and members
+    are serialized in declaration order -- no separate macro or extra code is needed.
+
+    ```cpp
+    namespace ns {
+        NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(person, name, address, age)
+    }
+
+    ns::person p{"Ned Flanders", "744 Evergreen Terrace", 60};
+    nlohmann::ordered_json j = p; // keys appear in declaration order: name, address, age
+    ```
+
+!!! note "No macro for non-default-constructible types"
+
+    There is currently no `NLOHMANN_DEFINE_TYPE_*`-style macro for types that are not
+    [DefaultConstructible](https://en.cppreference.com/w/cpp/named_req/DefaultConstructible). This is not an
+    intentional omission of documentation -- no such macro exists yet; see
+    [How can I use `get()` for non-default constructible/non-copyable types?](#how-can-i-use-get-for-non-default-constructiblenon-copyable-types)
+    for the manual pattern to use instead.
+
 ## How do I convert third-party types?
 
 This requires a bit more advanced technique. But first, let us see how this conversion mechanism works:
@@ -270,6 +313,49 @@ namespace nlohmann {
 }
 ```
 
+## Why can't I convert to/from `std::any`?
+
+`std::any` is intentionally excluded from `get<T>()`/generic conversion support, so `get<std::any>()` and
+containers like `std::map<std::string, std::any>` fail to compile by design -- there is no way to know, from a
+`json` value alone, which concrete type to store inside the `std::any`. To work with heterogeneous JSON values,
+dispatch on the value's type manually and construct the `std::any` (or extract from it) yourself:
+
+```cpp
+std::any value_to_any(const json& j) {
+    if (j.is_boolean())      { return j.get<bool>(); }
+    if (j.is_number_integer()) { return j.get<int>(); }
+    if (j.is_number_float()) { return j.get<double>(); }
+    if (j.is_string())       { return j.get<std::string>(); }
+    // ... handle other types (arrays, objects) as needed for your use case
+    return {};
+}
+
+json any_to_json(const std::any& a) {
+    if (a.type() == typeid(bool))        { return std::any_cast<bool>(a); }
+    if (a.type() == typeid(int))         { return std::any_cast<int>(a); }
+    if (a.type() == typeid(double))      { return std::any_cast<double>(a); }
+    if (a.type() == typeid(std::string)) { return std::any_cast<std::string>(a); }
+    return nullptr;
+}
+```
+
+## Why does serializing a `std::map`/`std::unordered_map` with non-string keys produce an array?
+
+A `std::map`/`std::unordered_map` whose key type is not string-like (e.g., `std::map<int, std::string>`) is
+serialized as a JSON *array* of 2-element `[key, value]` arrays, not as a JSON object -- JSON object keys must be
+strings, so the library cannot represent an integer-keyed map as an object.
+
+```cpp
+std::map<int, std::string> m{{1, "one"}, {2, "two"}};
+json j = m;
+// j is [[1,"one"],[2,"two"]], not {"1":"one","2":"two"}
+```
+
+## Why does `std::wstring` convert or dump incorrectly?
+
+The library assumes UTF-8 encoding internally, so `std::wstring` is not supported out of the box -- see the FAQ
+entry on [wide string handling](../home/faq.md#wide-string-handling) for why, and for a UTF-8 conversion recipe.
+
 ## Can I write my own serializer? (Advanced use)
 
 Yes. You might want to take a look at [`unit-udt.cpp`](https://github.com/nlohmann/json/blob/develop/tests/src/unit-udt.cpp) in the test suite, to see a few examples.

features/arbitrary_types/index.md

@@ -177,6 +177,31 @@ namespace ns {
 }
 ```
 
+Overriding conversions for natively-supported types
+
+The library already provides built-in `to_json`/`from_json` conversions for STL containers such as `std::vector`, `std::array`, and `std::map`. Defining your own free-function `to_json`/`from_json` overload for one of these container types directly (instead of for your own type) can conflict with the built-in overload during overload resolution, producing compiler errors ("no matching overloaded function", "call is ambiguous") that vary by compiler and library version. If you need different conversion behavior for a container type the library already handles, wrap it in your own type (or use `adl_serializer` specialization, as shown [above](#how-do-i-convert-third-party-types) for `boost::optional`) instead of trying to re-specialize `to_json`/`from_json` for the container type itself.
+
+Raw C-style arrays
+
+Members declared as raw C-style arrays (e.g., `char buf[1024]`) do not round-trip safely through `NLOHMANN_DEFINE_TYPE_*` macros or the default (de)serializers: `to_json` serializes any `char` array as a JSON *string* (matching the `std::string`-constructible overload), but the `from_json` overload for fixed-size arrays expects a JSON *array* and iterates it element-wise, which fails with a `type_error` when given a string. Use `std::string`, `std::array<char, N>`, or a manually written `to_json`/`from_json` pair for such members instead.
+
+Macros and `nlohmann::ordered_json`
+
+The `NLOHMANN_DEFINE_TYPE_*`/`NLOHMANN_DEFINE_DERIVED_TYPE_*` macros are generic over any `basic_json` specialization, including `nlohmann::ordered_json`. Simply use `ordered_json` as the target type and members are serialized in declaration order -- no separate macro or extra code is needed.
+
+```
+namespace ns {
+    NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(person, name, address, age)
+}
+
+ns::person p{"Ned Flanders", "744 Evergreen Terrace", 60};
+nlohmann::ordered_json j = p; // keys appear in declaration order: name, address, age
+```
+
+No macro for non-default-constructible types
+
+There is currently no `NLOHMANN_DEFINE_TYPE_*`-style macro for types that are not [DefaultConstructible](https://en.cppreference.com/w/cpp/named_req/DefaultConstructible). This is not an intentional omission of documentation -- no such macro exists yet; see [How can I use `get()` for non-default constructible/non-copyable types?](#how-can-i-use-get-for-non-default-constructiblenon-copyable-types) for the manual pattern to use instead.
+
 ## How do I convert third-party types?
 
 This requires a bit more advanced technique. But first, let us see how this conversion mechanism works:
@@ -265,6 +290,43 @@ namespace nlohmann {
 }
 ```
 
+## Why can't I convert to/from `std::any`?
+
+`std::any` is intentionally excluded from `get<T>()`/generic conversion support, so `get<std::any>()` and containers like `std::map<std::string, std::any>` fail to compile by design -- there is no way to know, from a `json` value alone, which concrete type to store inside the `std::any`. To work with heterogeneous JSON values, dispatch on the value's type manually and construct the `std::any` (or extract from it) yourself:
+
+```
+std::any value_to_any(const json& j) {
+    if (j.is_boolean())      { return j.get<bool>(); }
+    if (j.is_number_integer()) { return j.get<int>(); }
+    if (j.is_number_float()) { return j.get<double>(); }
+    if (j.is_string())       { return j.get<std::string>(); }
+    // ... handle other types (arrays, objects) as needed for your use case
+    return {};
+}
+
+json any_to_json(const std::any& a) {
+    if (a.type() == typeid(bool))        { return std::any_cast<bool>(a); }
+    if (a.type() == typeid(int))         { return std::any_cast<int>(a); }
+    if (a.type() == typeid(double))      { return std::any_cast<double>(a); }
+    if (a.type() == typeid(std::string)) { return std::any_cast<std::string>(a); }
+    return nullptr;
+}
+```
+
+## Why does serializing a `std::map`/`std::unordered_map` with non-string keys produce an array?
+
+A `std::map`/`std::unordered_map` whose key type is not string-like (e.g., `std::map<int, std::string>`) is serialized as a JSON *array* of 2-element `[key, value]` arrays, not as a JSON object -- JSON object keys must be strings, so the library cannot represent an integer-keyed map as an object.
+
+```
+std::map<int, std::string> m{{1, "one"}, {2, "two"}};
+json j = m;
+// j is [[1,"one"],[2,"two"]], not {"1":"one","2":"two"}
+```
+
+## Why does `std::wstring` convert or dump incorrectly?
+
+The library assumes UTF-8 encoding internally, so `std::wstring` is not supported out of the box -- see the FAQ entry on [wide string handling](https://json.nlohmann.me/home/faq/#wide-string-handling) for why, and for a UTF-8 conversion recipe.
+
 ## Can I write my own serializer? (Advanced use)
 
 Yes. You might want to take a look at [`unit-udt.cpp`](https://github.com/nlohmann/json/blob/develop/tests/src/unit-udt.cpp) in the test suite, to see a few examples.

features/comments.md

@@ -11,7 +11,7 @@ This library does not support comments *by default*. It does so for three reason
 
 3. It is dangerous for interoperability if some libraries add comment support while others do not. Please check [The Harmful Consequences of the Robustness Principle](https://tools.ietf.org/html/draft-iab-protocol-maintenance-01) on this.
 
-However, you can set parameter `ignore_comments` to `#!cpp true` in the [`parse`](../api/basic_json/parse.md) function to ignore `//` or `/* */` comments. Comments will then be treated as whitespace.
+However, you can set parameter `ignore_comments` to `#!cpp true` in the [`parse`](../api/basic_json/parse.md) function to ignore `//` or `/* */` comments. Comments will then be treated as whitespace. Combined with `ignore_trailing_commas` (also a `parse` parameter), this covers what is commonly referred to as **JSONC** (JSON with Comments, as used e.g. by Visual Studio Code's `.jsonc` files) -- comments and trailing commas, nothing more. This is a different, smaller extension than [JSON5](https://json5.org), which additionally allows unquoted keys, single-quoted strings, and other syntax changes that this library does not support.
 
 For more information, see [JSON With Commas and Comments (JWCC)](https://nigeltao.github.io/blog/2021/json-with-commas-comments.html).
 

features/comments/index.md

@@ -12,7 +12,7 @@ This library does not support comments *by default*. It does so for three reason
 
 1. It is dangerous for interoperability if some libraries add comment support while others do not. Please check [The Harmful Consequences of the Robustness Principle](https://tools.ietf.org/html/draft-iab-protocol-maintenance-01) on this.
 
-However, you can set parameter `ignore_comments` to `true` in the [`parse`](https://json.nlohmann.me/api/basic_json/parse/index.md) function to ignore `//` or `/* */` comments. Comments will then be treated as whitespace.
+However, you can set parameter `ignore_comments` to `true` in the [`parse`](https://json.nlohmann.me/api/basic_json/parse/index.md) function to ignore `//` or `/* */` comments. Comments will then be treated as whitespace. Combined with `ignore_trailing_commas` (also a `parse` parameter), this covers what is commonly referred to as **JSONC** (JSON with Comments, as used e.g. by Visual Studio Code's `.jsonc` files) -- comments and trailing commas, nothing more. This is a different, smaller extension than [JSON5](https://json5.org), which additionally allows unquoted keys, single-quoted strings, and other syntax changes that this library does not support.
 
 For more information, see [JSON With Commas and Comments (JWCC)](https://nigeltao.github.io/blog/2021/json-with-commas-comments.html).
 

features/conversions.md

@@ -84,6 +84,49 @@ which forces the explicit `get` form and can catch unintended conversions at com
     j_null.get_to(opt);                                     // ✅ std::nullopt
     ```
 
+!!! warning "`static_cast` and `get<std::optional<T>>()` are not guaranteed equivalent"
+
+    `operator ValueType()` (used by `static_cast` and implicit conversions) intentionally excludes
+    `std::optional<T>` from delegating to `get<T>()`, to avoid a constructor ambiguity with
+    `std::optional<T>`'s own converting constructor from `basic_json`. As a result,
+    `static_cast<std::optional<T>>(json_value)` goes through `std::optional<T>`'s own converting
+    constructor rather than through `get<std::optional<T>>()`, which can behave differently -- for example,
+    with a custom `adl_serializer<std::optional<T>>` specialization. Prefer `get<std::optional<T>>()`/`get_to()`
+    over `static_cast` for optional types.
+
+!!! warning "Converting to a fixed-size `std::array` does not check length"
+
+    Converting a JSON array to `#!cpp std::array<T, N>` does not check that the JSON array's size matches `N`:
+    if the JSON array is longer, the extra elements are silently dropped; if it is shorter, the remaining
+    `std::array` elements are left default-constructed. No exception is thrown in either case.
+
+    ```cpp
+    json j = {1, 2, 3, 4, 5};
+    auto a = j.get<std::array<int, 3>>();  // {1, 2, 3} -- elements 4 and 5 silently dropped
+    ```
+
+## Omitting a field when serializing `std::optional`
+
+By default, `to_json` for `std::optional<T>` writes either the value or `#!json null` -- there is no built-in way
+to make a field disappear from the serialized object entirely when the `std::optional` is `std::nullopt`. Because
+a specialization of `adl_serializer<std::optional<T>>` only controls how the *value* is converted (it cannot
+prevent the containing object's `to_json` from inserting the key in the first place), omission has to be
+implemented in the *containing* type's `to_json`:
+
+```cpp
+struct person {
+    std::string name;
+    std::optional<int> age;
+};
+
+void to_json(json& j, const person& p) {
+    j = json{{"name", p.name}};
+    if (p.age) {
+        j["age"] = *p.age;  // key is only inserted when the optional has a value
+    }
+}
+```
+
 ## Putting values in
 
 The reverse direction works the same way: assigning or constructing a `json` from a C++ value converts it to JSON.

features/conversions/index.md

@@ -138,6 +138,37 @@ auto opt = j_null.get<std::optional<std::string>>();  // ✅ std::nullopt
 j_null.get_to(opt);                                     // ✅ std::nullopt
 ```
 
+`static_cast` and `get<std::optional<T>>()` are not guaranteed equivalent
+
+`operator ValueType()` (used by `static_cast` and implicit conversions) intentionally excludes `std::optional<T>` from delegating to `get<T>()`, to avoid a constructor ambiguity with `std::optional<T>`'s own converting constructor from `basic_json`. As a result, `static_cast<std::optional<T>>(json_value)` goes through `std::optional<T>`'s own converting constructor rather than through `get<std::optional<T>>()`, which can behave differently -- for example, with a custom `adl_serializer<std::optional<T>>` specialization. Prefer `get<std::optional<T>>()`/`get_to()` over `static_cast` for optional types.
+
+Converting to a fixed-size `std::array` does not check length
+
+Converting a JSON array to `std::array<T, N>` does not check that the JSON array's size matches `N`: if the JSON array is longer, the extra elements are silently dropped; if it is shorter, the remaining `std::array` elements are left default-constructed. No exception is thrown in either case.
+
+```
+json j = {1, 2, 3, 4, 5};
+auto a = j.get<std::array<int, 3>>();  // {1, 2, 3} -- elements 4 and 5 silently dropped
+```
+
+## Omitting a field when serializing `std::optional`
+
+By default, `to_json` for `std::optional<T>` writes either the value or `null` -- there is no built-in way to make a field disappear from the serialized object entirely when the `std::optional` is `std::nullopt`. Because a specialization of `adl_serializer<std::optional<T>>` only controls how the *value* is converted (it cannot prevent the containing object's `to_json` from inserting the key in the first place), omission has to be implemented in the *containing* type's `to_json`:
+
+```
+struct person {
+    std::string name;
+    std::optional<int> age;
+};
+
+void to_json(json& j, const person& p) {
+    j = json{{"name", p.name}};
+    if (p.age) {
+        j["age"] = *p.age;  // key is only inserted when the optional has a value
+    }
+}
+```
+
 ## Putting values in
 
 The reverse direction works the same way: assigning or constructing a `json` from a C++ value converts it to JSON.

features/element_access/default_value.md

@@ -4,7 +4,8 @@
 
 In many situations, such as configuration files, missing values are not exceptional, but may be treated as if a default
 value was present. For this case, use [`value(key, default_value)`](../../api/basic_json/value.md) which takes the key
-you want to access and a default value in case there is no value stored with that key.
+you want to access and a default value in case there is no value stored with that key. This is equivalent to Python's
+`dict.get(key, default)`.
 
 ## Example
 

features/element_access/default_value/index.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-In many situations, such as configuration files, missing values are not exceptional, but may be treated as if a default value was present. For this case, use [`value(key, default_value)`](https://json.nlohmann.me/api/basic_json/value/index.md) which takes the key you want to access and a default value in case there is no value stored with that key.
+In many situations, such as configuration files, missing values are not exceptional, but may be treated as if a default value was present. For this case, use [`value(key, default_value)`](https://json.nlohmann.me/api/basic_json/value/index.md) which takes the key you want to access and a default value in case there is no value stored with that key. This is equivalent to Python's `dict.get(key, default)`.
 
 ## Example
 

features/element_access/unchecked_access.md

@@ -102,6 +102,20 @@ that the passed index is the new maximal index. Intermediate values are filled w
     `operator[]` can only be used with objects (with a string argument) or with arrays (with a numeric argument). For
     other types, a [`basic_json::type_error`](../../home/exceptions.md#jsonexceptiontype_error305) is thrown.
 
+## Performance: reserving array capacity
+
+There is no public `reserve(count)` member on `basic_json` for pre-allocating array capacity. If you are building
+a large array incrementally (e.g., via repeated `push_back()`) and know its final size ahead of time, you can
+reserve capacity via `get_ref()` to access the underlying `array_t` directly:
+
+```cpp
+json j = json::array();
+j.get_ref<json::array_t&>().reserve(1000);
+for (int i = 0; i < 1000; ++i) {
+    j.push_back(i);
+}
+```
+
 ## Summary
 
 | scenario                          | non-const value                                                                                                                                      | const value                                                                 |

features/element_access/unchecked_access/index.md

@@ -92,6 +92,18 @@ Exceptions
 
 `operator[]` can only be used with objects (with a string argument) or with arrays (with a numeric argument). For other types, a [`basic_json::type_error`](https://json.nlohmann.me/home/exceptions/#jsonexceptiontype_error305) is thrown.
 
+## Performance: reserving array capacity
+
+There is no public `reserve(count)` member on `basic_json` for pre-allocating array capacity. If you are building a large array incrementally (e.g., via repeated `push_back()`) and know its final size ahead of time, you can reserve capacity via `get_ref()` to access the underlying `array_t` directly:
+
+```
+json j = json::array();
+j.get_ref<json::array_t&>().reserve(1000);
+for (int i = 0; i < 1000; ++i) {
+    j.push_back(i);
+}
+```
+
 ## Summary
 
 | scenario                          | non-const value                                                                                                                        | const value                                                                                                      |

features/json_pointer.md

@@ -77,6 +77,11 @@ auto val2 = j.at(json::json_pointer("/nested/three/1"));    // false
 auto val3 = j.value(json::json_pointer("/nested/four"), 0); // 0
 ```
 
+!!! note "Creating intermediate levels that don't exist"
+
+    See the [`operator[]` notes](../api/basic_json/operator%5B%5D.md#return-value) for how array vs. object is
+    decided when a pointer creates intermediate levels that don't exist yet.
+
 ## Flatten / unflatten
 
 The library implements a function [`flatten`](../api/basic_json/flatten.md) to convert any JSON document into a JSON

features/json_pointer/index.md

@@ -73,6 +73,10 @@ auto val2 = j.at(json::json_pointer("/nested/three/1"));    // false
 auto val3 = j.value(json::json_pointer("/nested/four"), 0); // 0
 ```
 
+Creating intermediate levels that don't exist
+
+See the [`operator[]` notes](https://json.nlohmann.me/api/basic_json/operator%5B%5D/#return-value) for how array vs. object is decided when a pointer creates intermediate levels that don't exist yet.
+
 ## Flatten / unflatten
 
 The library implements a function [`flatten`](https://json.nlohmann.me/api/basic_json/flatten/index.md) to convert any JSON document into a JSON object where each key is a JSON Pointer and each value is a primitive JSON value (i.e., a string, boolean, number, or null).

features/parsing/json_lines.md

@@ -47,3 +47,6 @@ JSON Lines input with more than one value is treated as invalid JSON by the [`pa
     ```
     
     with a JSON Lines input does not work, because the parser will try to parse one value after the last one.
+
+    This is different from parsing a stream of *concatenated* (non-newline-delimited) JSON values, for which
+    `operator>>` does work -- see its [notes](../../api/operator_gtgt.md#notes) for details.

features/parsing/json_lines/index.md

@@ -69,3 +69,5 @@ while (input >> j)
 ```
 
 with a JSON Lines input does not work, because the parser will try to parse one value after the last one.
+
+This is different from parsing a stream of *concatenated* (non-newline-delimited) JSON values, for which `operator>>` does work -- see its [notes](https://json.nlohmann.me/api/operator_gtgt/#notes) for details.

features/parsing/parser_callbacks.md

@@ -58,6 +58,14 @@ table describes the values of the parameters `depth`, `event`, and `parsed`.
     | `array_end`    | 1     | `#!json [52.519444,13.406667]` |
     | `object_end`   | 0     | `#!json {"location":[52.519444,13.406667],"name":"Berlin"}` |
 
+!!! note "No built-in nesting depth limit"
+
+    The library has no built-in limit on recursion/nesting depth while parsing. A parser callback can only
+    *discard* content it has already parsed (by returning `#!c false`); it cannot make parsing fail once a
+    nesting limit is exceeded partway through reading a deeply nested value. If you need to reject over-deep
+    untrusted input outright, track `depth` in a callback and `throw` from it once your limit is exceeded (a
+    thrown exception propagates out of `parse()` as usual).
+
 ## Return value
 
 Discarding a value (i.e., returning `#!c false`) has different effects depending on the context in which the function
@@ -112,3 +120,51 @@ This approach has two limitations:
 
 For strict validation with precise error positions, implementing a [SAX interface](sax_interface.md) instead gives
 access to the parser's position information directly.
+
+## Recipe: streaming a large homogeneous array
+
+A common use case is a huge top-level array of many similarly-shaped objects, too large to hold entirely in
+memory as a `#!c json` value. A parser callback can hand off each completed element to a user function and then
+discard it, so memory usage stays bounded by a single element (plus the not-yet-parsed tail of the input) rather
+than the whole document. Since the top-level array's `array_start`/`array_end` are reported at `depth == 0` (its
+parent is the document root), the object elements it contains are reported at `depth == 1`:
+
+??? example
+
+    ```cpp
+    std::ifstream input("large_array.json");
+
+    auto callback = [](int depth, json::parse_event_t event, json& parsed) -> bool {
+        if (depth == 1 && event == json::parse_event_t::object_end) {
+            handle_element(parsed); // process the element, e.g. write it elsewhere
+            return false;           // discard it -- frees its memory before the next one is parsed
+        }
+        return true; // keep everything else, including the (by then empty) top-level array
+    };
+
+    json::parse(input, callback);
+    ```
+
+If the array's elements are scalars or nested arrays instead of objects, check for `parse_event_t::value` or
+`parse_event_t::array_end` at `depth == 1` instead. The same approach works for a top-level *object* of many
+homogeneous values by checking `object_end`/`value` events at `depth == 1` there too.
+
+## Recipe: max nesting depth via a callback
+
+Since there is no built-in nesting-depth limit (see the note above), a callback can enforce one manually by
+tracking the maximum `depth` seen and throwing once it is exceeded:
+
+??? example
+
+    ```cpp
+    constexpr int max_depth = 32;
+
+    auto callback = [](int depth, json::parse_event_t /*event*/, json& /*parsed*/) -> bool {
+        if (depth > max_depth) {
+            throw std::runtime_error("maximum nesting depth exceeded");
+        }
+        return true;
+    };
+
+    json::parse(input, callback);
+    ```

features/parsing/parser_callbacks/index.md

@@ -53,6 +53,10 @@ these calls are made to the callback function:
 | `array_end`    | 1     | `[52.519444,13.406667]`                              |
 | `object_end`   | 0     | `{"location":[52.519444,13.406667],"name":"Berlin"}` |
 
+No built-in nesting depth limit
+
+The library has no built-in limit on recursion/nesting depth while parsing. A parser callback can only *discard* content it has already parsed (by returning `false`); it cannot make parsing fail once a nesting limit is exceeded partway through reading a deeply nested value. If you need to reject over-deep untrusted input outright, track `depth` in a callback and `throw` from it once your limit is exceeded (a thrown exception propagates out of `parse()` as usual).
+
 ## Return value
 
 Discarding a value (i.e., returning `false`) has different effects depending on the context in which the function was called:
@@ -237,3 +241,44 @@ This approach has two limitations:
 - The thrown exception cannot carry a `parse_error`-style byte offset, because position tracking only exists inside the parser and lexer, not at the callback layer.
 
 For strict validation with precise error positions, implementing a [SAX interface](https://json.nlohmann.me/features/parsing/sax_interface/index.md) instead gives access to the parser's position information directly.
+
+## Recipe: streaming a large homogeneous array
+
+A common use case is a huge top-level array of many similarly-shaped objects, too large to hold entirely in memory as a `json` value. A parser callback can hand off each completed element to a user function and then discard it, so memory usage stays bounded by a single element (plus the not-yet-parsed tail of the input) rather than the whole document. Since the top-level array's `array_start`/`array_end` are reported at `depth == 0` (its parent is the document root), the object elements it contains are reported at `depth == 1`:
+
+Example
+
+```
+std::ifstream input("large_array.json");
+
+auto callback = [](int depth, json::parse_event_t event, json& parsed) -> bool {
+    if (depth == 1 && event == json::parse_event_t::object_end) {
+        handle_element(parsed); // process the element, e.g. write it elsewhere
+        return false;           // discard it -- frees its memory before the next one is parsed
+    }
+    return true; // keep everything else, including the (by then empty) top-level array
+};
+
+json::parse(input, callback);
+```
+
+If the array's elements are scalars or nested arrays instead of objects, check for `parse_event_t::value` or `parse_event_t::array_end` at `depth == 1` instead. The same approach works for a top-level *object* of many homogeneous values by checking `object_end`/`value` events at `depth == 1` there too.
+
+## Recipe: max nesting depth via a callback
+
+Since there is no built-in nesting-depth limit (see the note above), a callback can enforce one manually by tracking the maximum `depth` seen and throwing once it is exceeded:
+
+Example
+
+```
+constexpr int max_depth = 32;
+
+auto callback = [](int depth, json::parse_event_t /*event*/, json& /*parsed*/) -> bool {
+    if (depth > max_depth) {
+        throw std::runtime_error("maximum nesting depth exceeded");
+    }
+    return true;
+};
+
+json::parse(input, callback);
+```

features/types.md

@@ -151,6 +151,18 @@ In this class, the object's limit of nesting is not explicitly constrained. Howe
 
 Objects are stored as pointers in a `basic_json` type. That is, for any access to object values, a pointer of type `object_t*` must be dereferenced.
 
+### Converting maps with non-string keys
+
+A `std::map`/`std::unordered_map` whose key type is not string-like (e.g., `std::map<int, std::string>`) is
+converted to a JSON *array* of 2-element `[key, value]` arrays rather than a JSON object, because JSON object
+keys must be strings:
+
+```cpp
+std::map<int, std::string> m{{1, "one"}, {2, "two"}};
+json j = m;
+// j is [[1,"one"],[2,"two"]], not {"1":"one","2":"two"}
+```
+
 
 ## Arrays
 

features/types/index.md

@@ -150,6 +150,16 @@ In this class, the object's limit of nesting is not explicitly constrained. Howe
 
 Objects are stored as pointers in a `basic_json` type. That is, for any access to object values, a pointer of type `object_t*` must be dereferenced.
 
+### Converting maps with non-string keys
+
+A `std::map`/`std::unordered_map` whose key type is not string-like (e.g., `std::map<int, std::string>`) is converted to a JSON *array* of 2-element `[key, value]` arrays rather than a JSON object, because JSON object keys must be strings:
+
+```
+std::map<int, std::string> m{{1, "one"}, {2, "two"}};
+json j = m;
+// j is [[1,"one"],[2,"two"]], not {"1":"one","2":"two"}
+```
+
 ## Arrays
 
 [RFC 8259](https://tools.ietf.org/html/rfc8259) describes JSON arrays as follows: