📝 Document std::pair/std::tuple conversion and C++20 range-view construction (#5271)

Both had zero documentation anywhere in docs/mkdocs/. The tuple/pair
gap was first spotted in the very first git-log audit pass but never
turned into an actionable todo, so it persisted uncaught across four
subsequent passes.

- Document basic positional std::pair/std::tuple <-> json array
  conversion, plus #5016's reference-extraction capability
  (get<std::tuple<T&, T&>>() returning references into the stored
  array elements).
- Document #5205's new json-from-C++20-range-view constructor
  (e.g. nums | std::views::filter(...)).

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

docs/mkdocs/docs/api/macros/json_diagnostics.md

@@ -38,7 +38,8 @@ When the macro is not defined, the library will define it to its default value.
 
     Diagnostic messages can also be controlled with the CMake option
     [`JSON_Diagnostics`](../../integration/cmake.md#json_diagnostics) (`OFF` by default)
-    which defines `JSON_DIAGNOSTICS` accordingly.
+    which defines `JSON_DIAGNOSTICS` accordingly. Note this only applies when building the
+    library from source — see the pre-installed-package caveat on that page.
 
 ## Examples
 

docs/mkdocs/docs/features/conversions.md

@@ -47,6 +47,28 @@ json j = {{"one", 1}, {"two", 2}};
 auto m = j.get<std::map<std::string, int>>();  // {{"one", 1}, {"two", 2}}
 ```
 
+`#!cpp std::pair` and `#!cpp std::tuple` are also supported, converting positionally to and from a JSON array:
+
+```cpp
+json j = {1.0, "hello", 42};
+auto t = j.get<std::tuple<double, std::string, int>>();  // {1.0, "hello", 42}
+```
+
+!!! info "Extracting references into a tuple"
+
+    A tuple type may also hold references (e.g. `#!cpp std::tuple<double&, std::string&>`) to avoid copying: `get`
+    then returns a tuple of references pointing directly at the elements stored inside the `basic_json` array,
+    rather than a tuple of copies:
+
+    ```cpp
+    json j = {1.0, "hello"};
+    auto refs = j.get<std::tuple<double&, std::string&>>();
+    std::get<1>(refs) = "world";  // modifies j[1] in place
+    ```
+
+    A referenced type must be one the library actually stores (or an arithmetic type it can convert to/from);
+    otherwise this is a compile error.
+
 ## Implicit conversions
 
 By default, a JSON value implicitly converts to a compatible C++ type, so the explicit `get` call can often be omitted:
@@ -136,6 +158,20 @@ std::vector<int> numbers = {1, 2, 3};
 json j = numbers;   // [1,2,3]
 ```
 
+!!! info "Constructing from a C++20 range view"
+
+    A `json` array can also be constructed directly from a C++20 range view (`std::ranges::view`), such as the result
+    of `std::views::filter` or `std::views::transform` -- no intermediate container is needed:
+
+    ```cpp
+    std::vector<int> nums{1, 2, 37, 42, 21};
+    auto filtered = nums | std::views::filter([](int i) { return i > 10; });
+    json j(filtered);   // [37,42,21]
+    ```
+
+    This requires [`JSON_HAS_RANGES`](../api/macros/json_has_ranges.md) to be enabled and is unavailable on MinGW due
+    to incomplete C++20 ranges support there.
+
 ## Your own types
 
 The conversions above are built in for standard types. To make the same syntax work for **your own** types, provide

docs/mkdocs/docs/integration/cmake.md

@@ -135,6 +135,31 @@ Enable CI build targets. The exact targets are used during the several CI steps
 
 Enable [extended diagnostic messages](../home/exceptions.md#extended-diagnostic-messages) by defining macro [`JSON_DIAGNOSTICS`](../api/macros/json_diagnostics.md). This option is `OFF` by default.
 
+!!! warning "Does not apply to a pre-installed package"
+
+    This option only takes effect when building nlohmann/json from source as part of your own
+    CMake project (e.g. via [`FetchContent`](#fetchcontent) or [`add_subdirectory`](#external)).
+    It has **no effect** on a package that was already built and installed elsewhere (Homebrew,
+    vcpkg, a system package, etc.) — the resulting compile definition is baked into the exported
+    `nlohmann_jsonTargets.cmake` at install time, and `set(JSON_Diagnostics ON)` before
+    `find_package()` does not change it (verified against the Homebrew-installed package: the
+    exported target still carries a fixed `$<$<BOOL:OFF>:JSON_DIAGNOSTICS=1>`, regardless of any
+    variable set in the consuming project).
+
+    To enable extended diagnostics for a pre-installed package, override the imported target's
+    property directly after `find_package()`:
+
+    ```cmake
+    find_package(nlohmann_json REQUIRED)
+    set_target_properties(nlohmann_json::nlohmann_json PROPERTIES
+        INTERFACE_COMPILE_DEFINITIONS "JSON_DIAGNOSTICS=1")
+    ```
+
+    This only works cleanly when your project is the sole consumer of that imported target. If
+    nlohmann_json is pulled in from more than one place in your dependency graph with different
+    `JSON_DIAGNOSTICS` values, you may see a `"JSON_DIAGNOSTICS" redefined` compiler error, since
+    conflicting `-D` flags can end up on the same compile command line.
+
 ### `JSON_Diagnostic_Positions`
 
 Enable position diagnostics by defining macro [`JSON_DIAGNOSTIC_POSITIONS`](../api/macros/json_diagnostic_positions.md). This option is `OFF` by default.