std::variant enclosed in std::variant

[omarhogni]

I am having some issues parsing a json structure into std::variant defined within a std::variant.

I have created a basic failing std::variant test that is valid code and should work. But is not exactly my structure.

diff --git a/tests/json_test/json_test.cpp b/tests/json_test/json_test.cpp
index 88893af..2b79243 100644
--- a/tests/json_test/json_test.cpp
+++ b/tests/json_test/json_test.cpp
@@ -6475,6 +6475,35 @@ suite custom_object_variant_test = [] {
    };
 };

+suite recursive_variant = [] {
+   "recursive variant"_test = [] {
+      using Serializable = std::variant<std::variant<int, bool>, std::variant<std::string, double>>;
+      std::vector<Serializable> objects{
+         "text",
+         10.1,
+         10,
+         false
+      };
+
+      constexpr auto prettify = glz::opts{.prettify = true};
+
+      std::string data = glz::write<prettify>(objects);
+
+      expect(data == R"([
+   "text",
+   10.1,
+   10,
+   false
+])");
+
+      objects.clear();
+
+      expect(!glz::read_json(objects, data));
+
+      expect(data == glz::write<prettify>(objects));
+   };
+};
+
 struct hostname_include_struct
 {
    glz::hostname_include hostname_include{};

It seems there are not problems encoing the value of data:

[
   "text",
   10.1,
   10,
   false
]

Parsing the string into this particular type yields this result

[
   0
]

[stephenberry]

Thanks for the simple example and test case. This is not the simplest feature to support. We would need to deduce what types your nested variant could support.

We would have to start off making this code handle nested variants:

template <typename>
struct variant_types;

template <typename... Ts>
struct variant_types<std::variant<Ts...>>
{
   // TODO this way of filtering types is compile time intensive.
   using bool_types = decltype(tuplet::tuple_cat(
      std::conditional_t<bool_t<remove_meta_wrapper_t<Ts>>, tuplet::tuple<Ts>, tuplet::tuple<>>{}...));
   using number_types = decltype(tuplet::tuple_cat(
      std::conditional_t<num_t<remove_meta_wrapper_t<Ts>>, tuplet::tuple<Ts>, tuplet::tuple<>>{}...));
   using string_types = decltype(tuplet::tuple_cat( // glaze_enum_t remove_meta_wrapper_t supports constexpr types
                                                    // while the other supports non const
      std::conditional_t < str_t<remove_meta_wrapper_t<Ts>> || glaze_enum_t<remove_meta_wrapper_t<Ts>> ||
         glaze_enum_t<Ts>,
      tuplet::tuple<Ts>, tuplet::tuple < >> {}...));
   using object_types = decltype(tuplet::tuple_cat(
      std::conditional_t < reflectable<Ts> || readable_map_t<Ts> || writable_map_t<Ts> || glaze_object_t<Ts>,
      tuplet::tuple<Ts>, tuplet::tuple < >> {}...));
   using array_types =
      decltype(tuplet::tuple_cat(std::conditional_t < array_t<remove_meta_wrapper_t<Ts>> || glaze_array_t<Ts>,
                                 tuplet::tuple<Ts>, tuplet::tuple < >> {}...));
   using nullable_types =
      decltype(tuplet::tuple_cat(std::conditional_t<null_t<Ts>, tuplet::tuple<Ts>, tuplet::tuple<>>{}...));
};

However, even if we added support to handle nested variants, your type still fails to be auto-deducible (see variant documentation). This is because your top level variant supports both int and double, which are both JSON numbers.

I'm a bit surprised you can't just have a single variant of all these types for your use case. Can you give some insight into why this nested variant approach is useful to you?

I'm interested in this problem, but it is a bit complex and we'll need to understand the motivation well to come up with a good solution.

[omarhogni]

I have nested structures, each describing the configuration of some component. so f.e. component A can have some configuration and then component B can have a vector of A's configuration

struct A {
    std::variant<std::string, int> some_configuration;
}
struct B {
    std::vector<std::variant<std::monostate, A>> As;
}

here is a real life example were we are trying to abstract different motor types. Components utilizing a motor usually embed the motor configuration inside their own. So that the interface rendered by json-schema is coherent. And that works, but fails once the component has a variant of motor configuration or something else. f.e.

struct stationary {
    int some_parameter;
}
struct component {
    std::variant<motor_config, stationary> motor; // FAILS
}

We are aware of the limitations and have tagged the variants already as per the doc.

[stephenberry]

@omarhogni, Pardon me, I somehow missed your reply. Thanks for providing more info and a real life example. Super helpful.

I'm currently working on a codebase where we use a lot of variants, and we've been trying to figure out the best way to make hierarchical structures with them. I'll dive into this more when I have a chance.

[blear-cadence]

This may not be relevant, but have you taken a look at zpp bits (https://github.com/eyalz800/zpp_bits) to see how they handle variants?

[stephenberry]

Thanks, I have looked a bit at zpp_bits and it's really neat. But, it's actually really easy to support variants in binary because you can simply serialize and deserialize the index. It's not easy in JSON because nobody wants to have to write a number to indicate the type. Glaze will be able to support variants of variants when a type string is provided, there is an open issue to fix a bug concerning this: #1092. When an explicit type is provided this feature isn't too difficult. The challenge is auto deduction for nested variants. Auto deduction approaches of nested variants need to be carefully approached so that they don't generate too much binary, take too long to compile, or require too much runtime overhead.