From 6470d81f4ef4e44a1889163d515334cb76b167ff Mon Sep 17 00:00:00 2001 From: FourierTransformer Date: Tue, 10 Feb 2026 17:18:31 -0600 Subject: [PATCH 1/2] updated rockspec and to simdjson 4.2.4 --- ....rockspec => lua-simdjson-0.0.9-1.rockspec | 4 +- src/luasimdjson.cpp | 2 +- src/simdjson.cpp | 2 +- src/simdjson.h | 318 +++++++++++------- 4 files changed, 207 insertions(+), 119 deletions(-) rename lua-simdjson-0.0.8-1.rockspec => lua-simdjson-0.0.9-1.rockspec (96%) diff --git a/lua-simdjson-0.0.8-1.rockspec b/lua-simdjson-0.0.9-1.rockspec similarity index 96% rename from lua-simdjson-0.0.8-1.rockspec rename to lua-simdjson-0.0.9-1.rockspec index a8423cf..e2545c0 100644 --- a/lua-simdjson-0.0.8-1.rockspec +++ b/lua-simdjson-0.0.9-1.rockspec @@ -1,8 +1,8 @@ package="lua-simdjson" -version="0.0.8-1" +version="0.0.9-1" source = { url = "git://github.com/FourierTransformer/lua-simdjson", - tag = "0.0.8" + tag = "0.0.9" } description = { summary = "This is a simple Lua binding for simdjson", diff --git a/src/luasimdjson.cpp b/src/luasimdjson.cpp index 4004b88..e8d7500 100644 --- a/src/luasimdjson.cpp +++ b/src/luasimdjson.cpp @@ -15,7 +15,7 @@ #include "luasimdjson.h" #define LUA_SIMDJSON_NAME "simdjson" -#define LUA_SIMDJSON_VERSION "0.0.8" +#define LUA_SIMDJSON_VERSION "0.0.9" using namespace simdjson; diff --git a/src/simdjson.cpp b/src/simdjson.cpp index 687d98c..bcd6da6 100644 --- a/src/simdjson.cpp +++ b/src/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/src/simdjson.h b/src/simdjson.h index 2b9af43..1d6560e 100644 --- a/src/simdjson.h +++ b/src/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 @@ class value { */ simdjson_inline simdjson_result 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 @@ class value { * 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 @@ struct simdjson_result : public arm64::implementation_si simdjson_inline simdjson_result 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 @@ struct simdjson_result : public arm64::implementation_si * 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 - requires custom_deserializable - 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(obj)); } @@ -37298,7 +37303,7 @@ class string_builder { template requires(require_custom_serialization) - simdjson_inline void append(const T &val); + simdjson_inline void append(T &&val); // Support for string-like types template @@ -38234,7 +38239,9 @@ class document { simdjson_inline simdjson_result 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 @@ class document { * 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 @@ class object { simdjson_inline simdjson_result begin() noexcept; simdjson_inline simdjson_result 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 @@ class object { * 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 requires(require_custom_serialization) -simdjson_inline void string_builder::append(const T &val) { - serialize(*this, val); +simdjson_inline void string_builder::append(T &&val) { + serialize(*this, std::forward(val)); } template @@ -49740,7 +49751,9 @@ class value { */ simdjson_inline simdjson_result 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 @@ class value { * 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 @@ struct simdjson_result : public fallback::implementat simdjson_inline simdjson_result 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 @@ struct simdjson_result : public fallback::implementat * 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 - requires custom_deserializable - 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(obj)); } @@ -51763,7 +51779,7 @@ class string_builder { template requires(require_custom_serialization) - simdjson_inline void append(const T &val); + simdjson_inline void append(T &&val); // Support for string-like types template @@ -52699,7 +52715,9 @@ class document { simdjson_inline simdjson_result 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 @@ class document { * 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 @@ class object { simdjson_inline simdjson_result begin() noexcept; simdjson_inline simdjson_result 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 @@ class object { * 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 requires(require_custom_serialization) -simdjson_inline void string_builder::append(const T &val) { - serialize(*this, val); +simdjson_inline void string_builder::append(T &&val) { + serialize(*this, std::forward(val)); } template @@ -64704,7 +64726,9 @@ class value { */ simdjson_inline simdjson_result 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 @@ class value { * 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 @@ struct simdjson_result : public haswell::implementatio simdjson_inline simdjson_result 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 @@ struct simdjson_result : public haswell::implementatio * 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 - requires custom_deserializable - 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(obj)); } @@ -66727,7 +66754,7 @@ class string_builder { template requires(require_custom_serialization) - simdjson_inline void append(const T &val); + simdjson_inline void append(T &&val); // Support for string-like types template @@ -67663,7 +67690,9 @@ class document { simdjson_inline simdjson_result 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 @@ class document { * 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 @@ class object { simdjson_inline simdjson_result begin() noexcept; simdjson_inline simdjson_result 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 @@ class object { * 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 requires(require_custom_serialization) -simdjson_inline void string_builder::append(const T &val) { - serialize(*this, val); +simdjson_inline void string_builder::append(T &&val) { + serialize(*this, std::forward(val)); } template @@ -79668,7 +79701,9 @@ class value { */ simdjson_inline simdjson_result 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 @@ class value { * 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 @@ struct simdjson_result : public icelake::implementatio simdjson_inline simdjson_result 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 @@ struct simdjson_result : public icelake::implementatio * 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 - requires custom_deserializable - 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(obj)); } @@ -81691,7 +81729,7 @@ class string_builder { template requires(require_custom_serialization) - simdjson_inline void append(const T &val); + simdjson_inline void append(T &&val); // Support for string-like types template @@ -82627,7 +82665,9 @@ class document { simdjson_inline simdjson_result 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 @@ class document { * 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 @@ class object { simdjson_inline simdjson_result begin() noexcept; simdjson_inline simdjson_result 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 @@ class object { * 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 requires(require_custom_serialization) -simdjson_inline void string_builder::append(const T &val) { - serialize(*this, val); +simdjson_inline void string_builder::append(T &&val) { + serialize(*this, std::forward(val)); } template @@ -94747,7 +94791,9 @@ class value { */ simdjson_inline simdjson_result 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 @@ class value { * 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 @@ struct simdjson_result : public ppc64::implementation_si simdjson_inline simdjson_result 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 @@ struct simdjson_result : public ppc64::implementation_si * 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 - requires custom_deserializable - 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(obj)); } @@ -96770,7 +96819,7 @@ class string_builder { template requires(require_custom_serialization) - simdjson_inline void append(const T &val); + simdjson_inline void append(T &&val); // Support for string-like types template @@ -97706,7 +97755,9 @@ class document { simdjson_inline simdjson_result 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 @@ class document { * 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 @@ class object { simdjson_inline simdjson_result begin() noexcept; simdjson_inline simdjson_result 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 @@ class object { * 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 requires(require_custom_serialization) -simdjson_inline void string_builder::append(const T &val) { - serialize(*this, val); +simdjson_inline void string_builder::append(T &&val) { + serialize(*this, std::forward(val)); } template @@ -110142,7 +110197,9 @@ class value { */ simdjson_inline simdjson_result 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 @@ class value { * 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 @@ struct simdjson_result : public westmere::implementat simdjson_inline simdjson_result 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 @@ struct simdjson_result : public westmere::implementat * 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 - requires custom_deserializable - 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(obj)); } @@ -112165,7 +112225,7 @@ class string_builder { template requires(require_custom_serialization) - simdjson_inline void append(const T &val); + simdjson_inline void append(T &&val); // Support for string-like types template @@ -113101,7 +113161,9 @@ class document { simdjson_inline simdjson_result 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 @@ class document { * 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 @@ class object { simdjson_inline simdjson_result begin() noexcept; simdjson_inline simdjson_result 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 @@ class object { * 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 requires(require_custom_serialization) -simdjson_inline void string_builder::append(const T &val) { - serialize(*this, val); +simdjson_inline void string_builder::append(T &&val) { + serialize(*this, std::forward(val)); } template @@ -125014,7 +125080,9 @@ class value { */ simdjson_inline simdjson_result 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 @@ class value { * 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 @@ struct simdjson_result : public lsx::implementation_simdjs simdjson_inline simdjson_result 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 @@ struct simdjson_result : public lsx::implementation_simdjs * 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 - requires custom_deserializable - 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(obj)); } @@ -127037,7 +127108,7 @@ class string_builder { template requires(require_custom_serialization) - simdjson_inline void append(const T &val); + simdjson_inline void append(T &&val); // Support for string-like types template @@ -127973,7 +128044,9 @@ class document { simdjson_inline simdjson_result 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 @@ class document { * 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 @@ class object { simdjson_inline simdjson_result begin() noexcept; simdjson_inline simdjson_result 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 @@ class object { * 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 requires(require_custom_serialization) -simdjson_inline void string_builder::append(const T &val) { - serialize(*this, val); +simdjson_inline void string_builder::append(T &&val) { + serialize(*this, std::forward(val)); } template @@ -139899,7 +139976,9 @@ class value { */ simdjson_inline simdjson_result 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 @@ class value { * 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 @@ struct simdjson_result : public lasx::implementation_simd simdjson_inline simdjson_result 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 @@ struct simdjson_result : public lasx::implementation_simd * 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 - requires custom_deserializable - 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(obj)); } @@ -141922,7 +142004,7 @@ class string_builder { template requires(require_custom_serialization) - simdjson_inline void append(const T &val); + simdjson_inline void append(T &&val); // Support for string-like types template @@ -142858,7 +142940,9 @@ class document { simdjson_inline simdjson_result 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 @@ class document { * 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 @@ class object { simdjson_inline simdjson_result begin() noexcept; simdjson_inline simdjson_result 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 @@ class object { * 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 requires(require_custom_serialization) -simdjson_inline void string_builder::append(const T &val) { - serialize(*this, val); +simdjson_inline void string_builder::append(T &&val) { + serialize(*this, std::forward(val)); } template From 61be7c929f0a4ccf8269b8d3c4523474ca3bad92 Mon Sep 17 00:00:00 2001 From: FourierTransformer Date: Tue, 10 Feb 2026 17:26:59 -0600 Subject: [PATCH 2/2] updated README to indicate new Lua/simdjson version --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 98e345a..d24f3e7 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,9 @@ # lua-simdjson [![Build Status](https://github.com/FourierTransformer/lua-simdjson/actions/workflows/ci.yml/badge.svg?branch=master)](https://github.com/FourierTransformer/lua-simdjson/actions?query=branch%3Amaster) -A basic Lua binding to [simdjson](https://simdjson.org). The simdjson library is an incredibly fast JSON parser that uses SIMD instructions and fancy algorithms to parse JSON very quickly. It's been tested with LuaJIT 2.0/2.1 and Lua 5.1, 5.2, 5.3, and 5.4 on linux/osx/windows. It has a general parsing mode and a lazy mode that uses a JSON pointer. +A basic Lua binding to [simdjson](https://simdjson.org). The simdjson library is an incredibly fast JSON parser that uses SIMD instructions and fancy algorithms to parse JSON very quickly. It's been tested with LuaJIT 2.0/2.1 and Lua 5.1 to 5.5 on linux/osx/windows. It has a general parsing mode and a lazy mode that uses a JSON pointer. -Current simdjson version: 4.2.3 +Current simdjson version: 4.2.4 ## Installation If all the requirements are met, lua-simdjson can be install via luarocks with: