From 980f2ad3afb12729157b44ed33d2bac41b67b54b Mon Sep 17 00:00:00 2001
From: Daniel Lemire <daniel@lemire.me>
Date: Wed, 17 Dec 2025 20:33:11 -0500
Subject: [PATCH] 4.2.4

---
 CMakeLists.txt                      |   2 +-
 Doxyfile                            |   2 +-
 include/simdjson/simdjson_version.h |   4 +-
 singleheader/simdjson.cpp           |   2 +-
 singleheader/simdjson.h             | 318 ++++++++++++++++++----------
 singleheader/singleheader.zip       | Bin 8811967 -> 8820719 bytes
 6 files changed, 208 insertions(+), 120 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 7ae2fa382..e4cef5457 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -3,7 +3,7 @@ cmake_minimum_required(VERSION 3.14)
 project(
     simdjson
     # The version number is modified by tools/release.py
-    VERSION 4.2.3
+    VERSION 4.2.4
     DESCRIPTION "Parsing gigabytes of JSON per second"
     HOMEPAGE_URL "https://simdjson.org/"
     LANGUAGES CXX C
diff --git a/Doxyfile b/Doxyfile
index 4112fe85a..25965b297 100644
--- a/Doxyfile
+++ b/Doxyfile
@@ -38,7 +38,7 @@ PROJECT_NAME           = simdjson
 # could be handy for archiving the generated documentation or if some version
 # control system is used.
 
-PROJECT_NUMBER         = "4.2.3"
+PROJECT_NUMBER         = "4.2.4"
 
 # Using the PROJECT_BRIEF tag one can provide an optional one line description
 # for a project that appears at the top of each page and should give viewer a
diff --git a/include/simdjson/simdjson_version.h b/include/simdjson/simdjson_version.h
index 03ca42b37..2f7004b46 100644
--- a/include/simdjson/simdjson_version.h
+++ b/include/simdjson/simdjson_version.h
@@ -4,7 +4,7 @@
 #define SIMDJSON_SIMDJSON_VERSION_H
 
 /** The version of simdjson being used (major.minor.revision) */
-#define SIMDJSON_VERSION "4.2.3"
+#define SIMDJSON_VERSION "4.2.4"
 
 namespace simdjson {
 enum {
@@ -19,7 +19,7 @@ enum {
   /**
    * The revision (major.minor.REVISION) of simdjson being used.
    */
-  SIMDJSON_VERSION_REVISION = 3
+  SIMDJSON_VERSION_REVISION = 4
 };
 } // namespace simdjson
 
diff --git a/singleheader/simdjson.cpp b/singleheader/simdjson.cpp
index 687d98cd2..bcd6da639 100644
--- a/singleheader/simdjson.cpp
+++ b/singleheader/simdjson.cpp
@@ -1,4 +1,4 @@
-/* auto-generated on 2025-12-12 17:50:52 -0500. version 4.2.3 Do not edit! */
+/* auto-generated on 2025-12-17 20:32:36 -0500. version 4.2.4 Do not edit! */
 /* including simdjson.cpp:  */
 /* begin file simdjson.cpp */
 #define SIMDJSON_SRC_SIMDJSON_CPP
diff --git a/singleheader/simdjson.h b/singleheader/simdjson.h
index 2b9af4306..1d6560e80 100644
--- a/singleheader/simdjson.h
+++ b/singleheader/simdjson.h
@@ -1,4 +1,4 @@
-/* auto-generated on 2025-12-12 17:50:52 -0500. version 4.2.3 Do not edit! */
+/* auto-generated on 2025-12-17 20:32:36 -0500. version 4.2.4 Do not edit! */
 /* including simdjson.h:  */
 /* begin file simdjson.h */
 #ifndef SIMDJSON_H
@@ -2513,7 +2513,7 @@ namespace std {
 #define SIMDJSON_SIMDJSON_VERSION_H
 
 /** The version of simdjson being used (major.minor.revision) */
-#define SIMDJSON_VERSION "4.2.3"
+#define SIMDJSON_VERSION "4.2.4"
 
 namespace simdjson {
 enum {
@@ -2528,7 +2528,7 @@ enum {
   /**
    * The revision (major.minor.REVISION) of simdjson being used.
    */
-  SIMDJSON_VERSION_REVISION = 3
+  SIMDJSON_VERSION_REVISION = 4
 };
 } // namespace simdjson
 
@@ -35275,7 +35275,9 @@ public:
    */
   simdjson_inline simdjson_result<value> at(size_t index) noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -35309,7 +35311,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -35656,7 +35659,9 @@ public:
   simdjson_inline simdjson_result<arm64::ondemand::array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -35688,7 +35693,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the defaul because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -37157,9 +37163,8 @@ struct has_custom_serialization : std::false_type {};
 
 inline constexpr struct serialize_tag {
   template <typename T>
-    requires custom_deserializable<T>
-  constexpr void operator()(arm64::builder::string_builder& b, T& obj) const{
-    return tag_invoke(*this, b, obj);
+  constexpr void operator()(arm64::builder::string_builder& b, T&& obj) const{
+    return tag_invoke(*this, b, std::forward<T>(obj));
   }
 
 
@@ -37298,7 +37303,7 @@ public:
 
   template <typename T>
   requires(require_custom_serialization<T>)
-  simdjson_inline void append(const T &val);
+  simdjson_inline void append(T &&val);
 
   // Support for string-like types
   template <typename T>
@@ -38234,7 +38239,9 @@ public:
   simdjson_inline simdjson_result<array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -38278,7 +38285,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -39463,7 +39471,9 @@ public:
   simdjson_inline simdjson_result<object_iterator> begin() noexcept;
   simdjson_inline simdjson_result<object_iterator> end() noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -39511,7 +39521,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -46935,8 +46946,8 @@ simdjson_inline void string_builder::append(const T &opt) {
 
 template <typename T>
   requires(require_custom_serialization<T>)
-simdjson_inline void string_builder::append(const T &val) {
-  serialize(*this, val);
+simdjson_inline void string_builder::append(T &&val) {
+  serialize(*this, std::forward<T>(val));
 }
 
 template <typename T>
@@ -49740,7 +49751,9 @@ public:
    */
   simdjson_inline simdjson_result<value> at(size_t index) noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -49774,7 +49787,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -50121,7 +50135,9 @@ public:
   simdjson_inline simdjson_result<fallback::ondemand::array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -50153,7 +50169,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the defaul because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -51622,9 +51639,8 @@ struct has_custom_serialization : std::false_type {};
 
 inline constexpr struct serialize_tag {
   template <typename T>
-    requires custom_deserializable<T>
-  constexpr void operator()(fallback::builder::string_builder& b, T& obj) const{
-    return tag_invoke(*this, b, obj);
+  constexpr void operator()(fallback::builder::string_builder& b, T&& obj) const{
+    return tag_invoke(*this, b, std::forward<T>(obj));
   }
 
 
@@ -51763,7 +51779,7 @@ public:
 
   template <typename T>
   requires(require_custom_serialization<T>)
-  simdjson_inline void append(const T &val);
+  simdjson_inline void append(T &&val);
 
   // Support for string-like types
   template <typename T>
@@ -52699,7 +52715,9 @@ public:
   simdjson_inline simdjson_result<array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -52743,7 +52761,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -53928,7 +53947,9 @@ public:
   simdjson_inline simdjson_result<object_iterator> begin() noexcept;
   simdjson_inline simdjson_result<object_iterator> end() noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -53976,7 +53997,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -61400,8 +61422,8 @@ simdjson_inline void string_builder::append(const T &opt) {
 
 template <typename T>
   requires(require_custom_serialization<T>)
-simdjson_inline void string_builder::append(const T &val) {
-  serialize(*this, val);
+simdjson_inline void string_builder::append(T &&val) {
+  serialize(*this, std::forward<T>(val));
 }
 
 template <typename T>
@@ -64704,7 +64726,9 @@ public:
    */
   simdjson_inline simdjson_result<value> at(size_t index) noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -64738,7 +64762,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -65085,7 +65110,9 @@ public:
   simdjson_inline simdjson_result<haswell::ondemand::array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -65117,7 +65144,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the defaul because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -66586,9 +66614,8 @@ struct has_custom_serialization : std::false_type {};
 
 inline constexpr struct serialize_tag {
   template <typename T>
-    requires custom_deserializable<T>
-  constexpr void operator()(haswell::builder::string_builder& b, T& obj) const{
-    return tag_invoke(*this, b, obj);
+  constexpr void operator()(haswell::builder::string_builder& b, T&& obj) const{
+    return tag_invoke(*this, b, std::forward<T>(obj));
   }
 
 
@@ -66727,7 +66754,7 @@ public:
 
   template <typename T>
   requires(require_custom_serialization<T>)
-  simdjson_inline void append(const T &val);
+  simdjson_inline void append(T &&val);
 
   // Support for string-like types
   template <typename T>
@@ -67663,7 +67690,9 @@ public:
   simdjson_inline simdjson_result<array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -67707,7 +67736,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -68892,7 +68922,9 @@ public:
   simdjson_inline simdjson_result<object_iterator> begin() noexcept;
   simdjson_inline simdjson_result<object_iterator> end() noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -68940,7 +68972,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -76364,8 +76397,8 @@ simdjson_inline void string_builder::append(const T &opt) {
 
 template <typename T>
   requires(require_custom_serialization<T>)
-simdjson_inline void string_builder::append(const T &val) {
-  serialize(*this, val);
+simdjson_inline void string_builder::append(T &&val) {
+  serialize(*this, std::forward<T>(val));
 }
 
 template <typename T>
@@ -79668,7 +79701,9 @@ public:
    */
   simdjson_inline simdjson_result<value> at(size_t index) noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -79702,7 +79737,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -80049,7 +80085,9 @@ public:
   simdjson_inline simdjson_result<icelake::ondemand::array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -80081,7 +80119,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the defaul because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -81550,9 +81589,8 @@ struct has_custom_serialization : std::false_type {};
 
 inline constexpr struct serialize_tag {
   template <typename T>
-    requires custom_deserializable<T>
-  constexpr void operator()(icelake::builder::string_builder& b, T& obj) const{
-    return tag_invoke(*this, b, obj);
+  constexpr void operator()(icelake::builder::string_builder& b, T&& obj) const{
+    return tag_invoke(*this, b, std::forward<T>(obj));
   }
 
 
@@ -81691,7 +81729,7 @@ public:
 
   template <typename T>
   requires(require_custom_serialization<T>)
-  simdjson_inline void append(const T &val);
+  simdjson_inline void append(T &&val);
 
   // Support for string-like types
   template <typename T>
@@ -82627,7 +82665,9 @@ public:
   simdjson_inline simdjson_result<array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -82671,7 +82711,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -83856,7 +83897,9 @@ public:
   simdjson_inline simdjson_result<object_iterator> begin() noexcept;
   simdjson_inline simdjson_result<object_iterator> end() noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -83904,7 +83947,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -91328,8 +91372,8 @@ simdjson_inline void string_builder::append(const T &opt) {
 
 template <typename T>
   requires(require_custom_serialization<T>)
-simdjson_inline void string_builder::append(const T &val) {
-  serialize(*this, val);
+simdjson_inline void string_builder::append(T &&val) {
+  serialize(*this, std::forward<T>(val));
 }
 
 template <typename T>
@@ -94747,7 +94791,9 @@ public:
    */
   simdjson_inline simdjson_result<value> at(size_t index) noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -94781,7 +94827,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -95128,7 +95175,9 @@ public:
   simdjson_inline simdjson_result<ppc64::ondemand::array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -95160,7 +95209,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the defaul because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -96629,9 +96679,8 @@ struct has_custom_serialization : std::false_type {};
 
 inline constexpr struct serialize_tag {
   template <typename T>
-    requires custom_deserializable<T>
-  constexpr void operator()(ppc64::builder::string_builder& b, T& obj) const{
-    return tag_invoke(*this, b, obj);
+  constexpr void operator()(ppc64::builder::string_builder& b, T&& obj) const{
+    return tag_invoke(*this, b, std::forward<T>(obj));
   }
 
 
@@ -96770,7 +96819,7 @@ public:
 
   template <typename T>
   requires(require_custom_serialization<T>)
-  simdjson_inline void append(const T &val);
+  simdjson_inline void append(T &&val);
 
   // Support for string-like types
   template <typename T>
@@ -97706,7 +97755,9 @@ public:
   simdjson_inline simdjson_result<array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -97750,7 +97801,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -98935,7 +98987,9 @@ public:
   simdjson_inline simdjson_result<object_iterator> begin() noexcept;
   simdjson_inline simdjson_result<object_iterator> end() noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -98983,7 +99037,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -106407,8 +106462,8 @@ simdjson_inline void string_builder::append(const T &opt) {
 
 template <typename T>
   requires(require_custom_serialization<T>)
-simdjson_inline void string_builder::append(const T &val) {
-  serialize(*this, val);
+simdjson_inline void string_builder::append(T &&val) {
+  serialize(*this, std::forward<T>(val));
 }
 
 template <typename T>
@@ -110142,7 +110197,9 @@ public:
    */
   simdjson_inline simdjson_result<value> at(size_t index) noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -110176,7 +110233,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -110523,7 +110581,9 @@ public:
   simdjson_inline simdjson_result<westmere::ondemand::array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -110555,7 +110615,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the defaul because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -112024,9 +112085,8 @@ struct has_custom_serialization : std::false_type {};
 
 inline constexpr struct serialize_tag {
   template <typename T>
-    requires custom_deserializable<T>
-  constexpr void operator()(westmere::builder::string_builder& b, T& obj) const{
-    return tag_invoke(*this, b, obj);
+  constexpr void operator()(westmere::builder::string_builder& b, T&& obj) const{
+    return tag_invoke(*this, b, std::forward<T>(obj));
   }
 
 
@@ -112165,7 +112225,7 @@ public:
 
   template <typename T>
   requires(require_custom_serialization<T>)
-  simdjson_inline void append(const T &val);
+  simdjson_inline void append(T &&val);
 
   // Support for string-like types
   template <typename T>
@@ -113101,7 +113161,9 @@ public:
   simdjson_inline simdjson_result<array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -113145,7 +113207,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -114330,7 +114393,9 @@ public:
   simdjson_inline simdjson_result<object_iterator> begin() noexcept;
   simdjson_inline simdjson_result<object_iterator> end() noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -114378,7 +114443,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -121802,8 +121868,8 @@ simdjson_inline void string_builder::append(const T &opt) {
 
 template <typename T>
   requires(require_custom_serialization<T>)
-simdjson_inline void string_builder::append(const T &val) {
-  serialize(*this, val);
+simdjson_inline void string_builder::append(T &&val) {
+  serialize(*this, std::forward<T>(val));
 }
 
 template <typename T>
@@ -125014,7 +125080,9 @@ public:
    */
   simdjson_inline simdjson_result<value> at(size_t index) noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -125048,7 +125116,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -125395,7 +125464,9 @@ public:
   simdjson_inline simdjson_result<lsx::ondemand::array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -125427,7 +125498,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the defaul because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -126896,9 +126968,8 @@ struct has_custom_serialization : std::false_type {};
 
 inline constexpr struct serialize_tag {
   template <typename T>
-    requires custom_deserializable<T>
-  constexpr void operator()(lsx::builder::string_builder& b, T& obj) const{
-    return tag_invoke(*this, b, obj);
+  constexpr void operator()(lsx::builder::string_builder& b, T&& obj) const{
+    return tag_invoke(*this, b, std::forward<T>(obj));
   }
 
 
@@ -127037,7 +127108,7 @@ public:
 
   template <typename T>
   requires(require_custom_serialization<T>)
-  simdjson_inline void append(const T &val);
+  simdjson_inline void append(T &&val);
 
   // Support for string-like types
   template <typename T>
@@ -127973,7 +128044,9 @@ public:
   simdjson_inline simdjson_result<array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -128017,7 +128090,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -129202,7 +129276,9 @@ public:
   simdjson_inline simdjson_result<object_iterator> begin() noexcept;
   simdjson_inline simdjson_result<object_iterator> end() noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -129250,7 +129326,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -136674,8 +136751,8 @@ simdjson_inline void string_builder::append(const T &opt) {
 
 template <typename T>
   requires(require_custom_serialization<T>)
-simdjson_inline void string_builder::append(const T &val) {
-  serialize(*this, val);
+simdjson_inline void string_builder::append(T &&val) {
+  serialize(*this, std::forward<T>(val));
 }
 
 template <typename T>
@@ -139899,7 +139976,9 @@ public:
    */
   simdjson_inline simdjson_result<value> at(size_t index) noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -139933,7 +140012,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -140280,7 +140360,9 @@ public:
   simdjson_inline simdjson_result<lasx::ondemand::array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -140312,7 +140394,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the defaul because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -141781,9 +141864,8 @@ struct has_custom_serialization : std::false_type {};
 
 inline constexpr struct serialize_tag {
   template <typename T>
-    requires custom_deserializable<T>
-  constexpr void operator()(lasx::builder::string_builder& b, T& obj) const{
-    return tag_invoke(*this, b, obj);
+  constexpr void operator()(lasx::builder::string_builder& b, T&& obj) const{
+    return tag_invoke(*this, b, std::forward<T>(obj));
   }
 
 
@@ -141922,7 +142004,7 @@ public:
 
   template <typename T>
   requires(require_custom_serialization<T>)
-  simdjson_inline void append(const T &val);
+  simdjson_inline void append(T &&val);
 
   // Support for string-like types
   template <typename T>
@@ -142858,7 +142940,9 @@ public:
   simdjson_inline simdjson_result<array_iterator> end() & noexcept;
 
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -142902,7 +142986,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -144087,7 +144172,9 @@ public:
   simdjson_inline simdjson_result<object_iterator> begin() noexcept;
   simdjson_inline simdjson_result<object_iterator> end() noexcept;
   /**
-   * Look up a field by name on an object (order-sensitive).
+   * Look up a field by name on an object (order-sensitive). By order-sensitive, we mean that
+   * fields must be accessed in the order they appear in the JSON text (although you can
+   * skip fields). See find_field_unordered() and operator[] for an order-insensitive version.
    *
    * The following code reads z, then y, then x, and thus will not retrieve x or y if fed the
    * JSON `{ "x": 1, "y": 2, "z": 3 }`:
@@ -144135,7 +144222,8 @@ public:
    * missing case has a non-cache-friendly bump and lots of extra scanning, especially if the object
    * in question is large. The fact that the extra code is there also bumps the executable size.
    *
-   * It is the default, however, because it would be highly surprising (and hard to debug) if the
+   * We default operator[] on find_field_unordered() for convenience.
+   * It is the default because it would be highly surprising (and hard to debug) if the
    * default behavior failed to look up a field just because it was in the wrong order--and many
    * APIs assume this. Therefore, you must be explicit if you want to treat objects as out of order.
    *
@@ -151559,8 +151647,8 @@ simdjson_inline void string_builder::append(const T &opt) {
 
 template <typename T>
   requires(require_custom_serialization<T>)
-simdjson_inline void string_builder::append(const T &val) {
-  serialize(*this, val);
+simdjson_inline void string_builder::append(T &&val) {
+  serialize(*this, std::forward<T>(val));
 }
 
 template <typename T>
diff --git a/singleheader/singleheader.zip b/singleheader/singleheader.zip
index 6a71b16c2cdda3213011cdf2933165ea4a602b57..97a79aebea03384cb44d619f8d3f9baf7edaf283 100644
GIT binary patch
delta 11837
zcmeI2dr(x@9mli0L51ZJFoJSHMNn9mWfjBA1$ih4EDA1)(p}i)x$JJ(2O0%d@p2Pm
zFRMm=G3h9#u`$7pI58g0bab7LDM@WhJ4qYTPRdN}WTK|E)21znqy61`7fLjN8QH&f
zVCFk>e)nF^-u<0(KKr}hd#>F%;q&+Nulj^3OT2v|p5p%E-#Ai}^3{*Zj)bj^O{Zki
zj5JwB+FB|_x<)FMP&Qq=x!Gu-<Pw=g4vO66EB3QAE23F1n)RkxADZ>0SwEWfr`Z6S
z4W!v1nw>|p^J#Vg%?8tK2+fLVHk4+=Xf~W?BWU(%nvJB{D4JbJv(M1%BASh+*%+E#
zOtVX9HkM{7nvJ8`c$!^Gv&-IPm#Y-P+&!MZz2r0PHqBGoZSYUUa>-2h%HX{cMQ*~C
zG%tDlvEQafkuYn*7LiB}1D&l>=(Qw-GiPlHs1>M0R1#_>Y85IOm4cF>R->e-RFn*r
zhLWS!pw^<&QR`68lC!pqzPGxmygih$U8`$PG3yNGW=pe8mrQl&s5YI(Kv|kJmLQ6v
zR#FYkI=$9RwOP#;s!m5~>g#o8vrbDja~J7^9=O&XN@FtVH0={7ino@RQ5M~93zewR
zTbhj4#wKcy(Mr{841C97l)1Ip<mx_2LT%OQ;KHHo$kZfCW6)AYldfH3F}Bz2q8g0t
zc*u3H&4$Ulofvd-I>&NIM4WM%A-+*69i`PZXsmk6)GmyW`$chNcw!RYS-sI<(;1p|
zhI*X@PQTe1MRH@Z!$jn>U#Uw{!E`yRslP4LABOg;0?D=QnZ_W`%GH-%V7i{O5Y#VZ
z$H7QXe#VrLT9vt)4~gSozRl~2(iutOnEVRYhYW?3$-%xV6Z6V_CWbqN*4R7S6F?y@
zn-9*FnUY7&k}*T(A0C42aKR$@k0EP0T!(5&gxR9a$iUgqp=sA<Rpulb>spdP@^l?b
zJ~d{Y5Am*~63CJ6te+h7tnn)GB14zT&-gvjVDNK$^mm?>kwYTD)oz1<;nE=T;HYwG
zz?0>M(Tr!Ka!~703Zfa$^}WE&BM7aiiiXpwm~gM8BnUmbV<8#1b@1gd7<tt<14iU~
zBOqB@RRDdpdA=}kfBmZdTP5LeuO&;`Kd>v5QC`g>%BvgFyF4xLZlmm&e}Ms{rwRqk
z!u)^a=ka0x0aY@D_!LFJzzaqG(EWAkFF^78f@n~GQ@Reu;)<hT@rA-*;{2vm>J850
z`4M2cSm*%h)$SUgK5Y3I46hf)K)0VJ8EU)mtTeaSkBq4^#Ug@nv6p9!2(lb=fZ0Ko
z6J+^X?<ZObkqjamv0ZS-hl6h3OuUu-u;ATE-b#YOajxJDDCBj&CfMpY=vg_QJ%8V>
z1!2CQE)0ae7-bO2I#D=e@vJnt3(5%L>?KLAgyG_a-wfB!V@7g|P#aO3P{m{<x8!AZ
zT2d>_8`gkWTcv@M&lRWj-YU6tYjeY&JT2#L1G2PNsRw6pnG4A0dX)-3<biBY-x>~z
zpH=u11oGE`o|QyosA56cG8iaPRZO-haC}&b1uC8(s~sx+tV&@9yCI4N<&|DSN&8Vq
z`HGnkdqrIS&Q!$Sm6TIJHCtE0E@}C89=0%fjNq}rIqW|2NQc<vXSF!KGKe^0l)5?M
za?jF_KmH2D<#VOpw<Q2Z`q~14Cjb{Ru{V^c3e*<VRuX%o^7c#9vKPCG1ND26(R``Q
zV5v-!wcA9uJPRCdG#$oXtW5`MZ+1M4J*Zhk(0Xuqp6kGUwJEN{|3lt&;J^6nT?f8b
z-gPkbsj9#fu2J$ig+~kr{<?wVDhr_3P$OKzhmIGsV>n|X#x)d&^E-Tia_(G66i4#q
zqDv=LHRA%tUxVryF>ZgQ`db*k)3GBEQZ83V2`rxol>*Qw!YOCp#Ea+1{y5nuS4{s~
zH8Da_t$t(s&N;+Shxo~)!C2C+MKCg4AH<y8yaQE(+KJjlPHwK19iEo%LlUuEsI2$>
zcc+YZKG<W`GT!-c-mN9hyFb`II*0o2@|R^<o|PBQe+bva3$^n^%T+sb;p}T?uK$$&
zt*ThTMRr963^wpo-Kc=#(TKWfOk#p2akiM7)0{tyens$_x>E%GiqSc;K2FwqC1IHC
z;rdMoiF(1WfSa^BO9&mG>r;-4HKAODmEwuQad0+hqhRELJ`+YRYM&uXE)?c?gCe9c
z4(t~T?O=bX#^25_^+ZJenphvD_pBA*X4`{HK7+|eX;C^<1F;V`4l~mt8UJmHE#2?i
zG!Lkc>X-9u{^ELs7*=o6P#mBEt?6}4i?#{XOj@)p2??Gy9`3S4$iUBALg#r_c97TV
zf9bP?*M5A9uf4IAK%@>;>#S@JQ2twAD0I!YxULz~CoRPEN$VMr0P3nwTN7upJ~IE<
z`Ym_)+_))-NXJ{pXwMo9w;0PfNewV`&)@>Jetlap>HA#YFjojqR|pGPvzq+*8W?sy
z-<k(QT)5<hGKDF3w4n?rBg#a|9nUS9)@)`JsqI9OYGyw0tQqP?hl2{~(1KHKbM31r
zky}(A=5Q#V><#_Ib_sjs?nrKbgloIRM7RU^)}(vEI5t|qvC$gnDttFum(Ik~_cmDv
zr&!74wMJ|597-QAeEBJ=tk@k0A(y-7!DhK79r%!|d5OBpcCy{mmbZKMQMg{&Vg6e9
zw{?K4dmSUbZ$ovUcBA$X@%`u94}5<Wdpr!NjOg?!n=5kC_6CBz(JYj)w<|44jPmGS
zqCC1U=9iu}5bi2kVSscufOxRe^&YPz&Yr=C{Cm8Sn+L=&a?tJv;=g2vf&EI>C6L~?
zM{-YZ3yAua&aVPIE3tp`0>|5(l;BScY3#U#WRpe8ADg{3(LdOkJn2lhf`Z<`&i=u!
z;{u&O9_(5+6P?MquAfe!Gi<)uwU{%9S3&8`t}4M7o;*hI*r^`R8Y6d<!33xMsM)jf
z;$~-o2ZQu-kL&dw4+cKO*L%splR>(s#}CwbMIV5)x+f0GHWbN)mUCH-3~>28+yB5O
z5mwYaP%Z>}evyQm_;Bz2ZWAbnl?C7o=#B-)L)%6ey3xIE;)*CD{d4zX5iy85-WM^~
z8tkb3r~{}Ta;@Ru>z&{I%fR5aJKTCl|JV^Qu>%}Rti7^F_gcSX?Und7LND$V{~sE2
B9Nqu`

delta 4372
zcmb7I3s6(p8Q$=IDFIpKr9@Cb7D9j^ngqPK1T5ikeeCjZ#XtZx5C{_RfdqWq+?m!r
z(%SNOw;dbZb*pQ)30=*ZmTkq|Zbxgkjia;eb~`laOlNka-BfpW`dX*w-h@j4kt{Rc
z@c;Mx=j7b~`~Uy^=YDQ`J?Q$w*MeecO<+*mbKGASI=$O*^rqw6u^UtJC3!`PLYbm4
zUy>s$l*y!${<ed?2fDi?a%sM_0I1US8OITWL<|aGP#}YX7!=H)5C(-ZD2zej42ob-
zB!i+Dw2VQ^85GSRF@s_l6w9C$42omW^9)+apj8ZtXHWuz5*d`lpkxNEX3!c2r7%ds
zptTH2Wl$P})?GvE>!{`29`ichn3T(#pOeesF|}U0)LvP#S4@?r|GXfeAoc8>yj3{1
zFMWqdQ~*=ItdW7ml)i$!)Spg}L6AwXfgp?E1%hmX90DmpE`f|7k076*fIv=ANU)Kh
zh+q@JW_+n%app2)j4PwDw$I=e;pjBwYe9fJmEuTKwq$?zp*G^rY`peXZLA2(P7P}E
zVB~^wKZtiLL-FlK<>3fn_E8bIzTbHRoN3AnAhQ;yf$LLk3RpE|d4j6uBsq3{v#c>-
z;jfIHuiGBLS)_t1OS#)44QDpf9?5QNNQU7ndd1v<cyK4w%roYnMS}Y$`W((U9#fC>
zhk{_@uZoyapn|dUOTApgsi9zevv>g9=IW5qn7Rm{Vhw9ScC|GgsEftT;Oy>C#Z+ny
zE8>>{>*M;DJ(BTPsxe6UpPtN}QUrtcz9I<R4~sKEl3ue6WP{3JxPCP>a`e6;30y|g
zR!kn*AHzsNbt>$5t9}jq$EaElk{(q~V0ViiH}|ND#o)Z44#yXct1h1P@hT=>Z4X`O
zEyBs$O;~I$&NT_vt0SIjHzvXpg^h*`4|mohC81#5(-;9&A1hVBtKE~j9QeGZGzPTF
zk`QoJR@?${M#(A=D@!6_BCbO2qjuk=^Eof1!N|9Y_krD|<9SU5<EzETz@1UC9*i4w
z5|5+YQ@UC~N(FmXN%>qizKdNCbRUSIYC;vmZ6+G_wlz-9s(5dE<68l&A-{xR3jsw?
ziVgW&3yy(ox+w(C*tUkigU^~)1@<?0Vo}pe@5F-h^<c&5w59=6Cv&1;VoI?N+&wR?
z0INYY%M3gG{#HEv{)^RS!GnI~!07pHn}GVeG8JfBc@mI32*<{Ova^dM18*cbKq7iZ
z$^!dHnFbpZOr4A70dFhoR<?O&5lPOHS=c_JzAf?zr0;!4ohbwokU&EC)wAkr(Lyxk
zEC<cC$_Q}(O#K6pNcIN7KTh`jmVbuHGs7w2<&TP<8EnF9<6&$0AN`IxVH#+&DwFug
zW9iBYf^7ufAgIK2rRKY6aW>t|i-n;5FeJ<}t#M3OJ^G8VWxx0W$sM{A=ps6l=L!Z|
zYbjpEe-5mn7Gcd^M6Uz!xw`GZOV*F7%X#V9tP$H>u)kU7EqpVonwv^_s@Lo@qlPA_
z@<2;-qx>{A@Xz?dMWifDKhp0D0_U!stFg0RnJWUZg0?JKufqT36Ck?8T2hw0mBtew
zjY+ld&Iu5kqV|p1*uX^H>1S9lcLgq%s6H%VfnYnq4uYLna%Y$A^ixP@NeYuRe)-9l
z!qWcHtlhG^2(;z(g?Qvl9W27@#K#SZz-Qx(M6$6*nGQ2*BzB*x>sXkVEIFU>*!lX4
zL4tGD^ZdH+$Mtjl`rdEqef>&QfBpJ)69}&Z*7q91fy$&KKo!-v4gctBL!2M!$C9E?
zu$$l&f<5FAXiC2N6o-3jrd=wQ^I66fPL}?v3DaNgo%-bKl91n4=qZlQ%;tDcar}Ku
zbN2!|ur{SRa$&Q<-bic4H_}=XX5G97zQ|~qJuN*k{8?s;%{PYet@4(`jIh}yY8hyS
zZH|<*C3>B!(Urj;%*9f0-fWH`$C)k+i#O^v^a`sk5#m0px}N9~z<7K(oXwup5wsGt
z5wzp%$$eey;w-o|vHZ!!MjhEtZ~#Xg(ce!OcHmzo7!4g=AX{$m7QEAY^%Wp<3`&7k
zb;fZ6!QdWxB^JcT$}rIX)yIKL-4!w#T(cR(kv+*kI~tZ@J06q;dPl!7iXG#Fb`jX8
zh_So6lk_|%%5pJLO@YGZ=JbGM*(6V*%}Cxvn^6}}v}rvao9=k%8v%}gcFaHKe)_0m
z?lIRH*As!yi922XhXL;>Dx}++Uc^ybfmfa8;+$)gVUr(u=54OHrC9A{0|EEHo4|;*
zmwPTg<6yJzTIo61_+DjAow0y#Q`ia3K|G=9y>e4<tslHs<$?Wf?|%I68dJ-HY~%ZK
zEZJky1upCnJ)O5J`A{jy)MX0bCHKARTuyp{rCLouwf3cZ>RwB0U+KKM*W1>2#hZ(%
zeSHmnx34f#V`>F)*I}>wv+wn8@~E8q!FsQkta_w33{waD*@J>FmdZkYRhg+bg0&?a
zA~;NNgy1N)B@B$6SUmTvpRSh8RzRn106T5REVqRp_Jf3VD#3bAHn=B;R$<w%2WuB~
zKW71y&eRUp_@R}+HGH0fi60>9^MnLb)l*0LE6|Lc?=&(H>G){y(i4HZ6!_q_Ic*++
zj^CNznI%xVe019UL!lqI?U*+I?WE6ZJ+n&$cZInf=&2zur{f=*6&{u6RI+kN%&B46
z{>jjv{O6Qk)!KN{dv)Pg<yHRb!mm1ff5>}vas6UY47|$UUnEI~3c+=KFxuxCe~IBd
zHd;y7f>+@0CsJMmZJDk?kg~api+6y((eS<|lFtl_W!PdlZn2!OSWY@Dr<mcz<IGhq
p+01ABmhn>&mPE#pXz3jcoB6N-17OLY{|R9nEYgsoJ`4E(@_*mJ5)A+V