Workaround for Const Members？

[WanZhiQiu-ac]

Hi, I noticed there's an option called error_on_const_read, but I'm having trouble fully grasping the underlying design philosophy behind it. It seems reasonable when we use the following approach:

my_struct s{};
auto ec = glz::read_json(s, buffer);

In this case, if s contains a const data member that has already been initialized, it makes sense to trigger an error or silently skip this member. However, it feels less reasonable when we use this approach:

auto s = glz::read_json<my_struct>(buffer);
if (s) {
  s.value();
}

Here, since the object is being created from scratch, we should be able to initialize the const data member during its construction. My questions are:

1. What is the underlying design philosophy behind the error_on_const_read option?
2. Is there any workaround that would allow us to use const members in our struct?

[stephenberry]

1 - What is the underlying design philosophy behind the error_on_const_read option?

Typically error_on_const_read is kept off and const members are skipped. Sometimes we want to error when an attempt is made to read into the const variable, so we know when we are discarding input data, therefore this option exists. It seems like you have a firm grasp of these.

Notes on read_json API

Your core question has to do with initializing structs with const members from JSON input. This syntax: auto s = glz::read_json<my_struct>(buffer); uses default construction so that we start with the default values of the struct and then modify these values based on the input JSON. This is very useful, as it allows users to put their defaults in the struct and then parsing logic can be dependent upon defaults. This might include pre-allocating memory for performance reasons, or setting an initialization state in the struct that affects how fields are parsed.

2 - Is there any workaround that would allow us to use const members in our struct?

Not initialized from within the Glaze API. Right now you need to read into a structure of input arguments needed for your constructor and then construct your type with a non-default constructor outside of the read_json call.

Can support be added?

There are two main challenges that would need to be overcome. In cases where a default constructor does not exist we need to know the type information of the input arguments. Constructors can be templated, so the developer may need to select the types they want. This means the developer needs an API that allows them to list out all the input types. But, the question then must be posed whether these input types must conform to the same JSON input as the input types or the class layout? These could be too different things. The glz::custom wrapper solves this complex problem, allowing different input JSON from the underlying type layout, but it still requires the class to be default constructible so that it can be passed to the custom lambda.

Note that we wouldn't want to just solve this problem for top level types like my_struct in glz::read_json<my_struct>. my_struct could contain types that are non-default constructible and we'd want our solution to support these nested cases (think of uses in dynamic types like std::vector). This means that the type information for input arguments cannot exist in an API to read_json, but must exist elsewhere.

In order for reflection to work we often use member object pointers. The problem is that we need an allocated struct in order to use member object pointers. But, an allocated parent structure can't exist if we can't default construct it. This means that we would need the ability to construct the entire nested tree in one go. This would be too much of a burden on developers.

Even if all this were solved in some elegant way, we then need to handle cases where the input JSON doesn't match the input parameters to the constructor, and thus have a means of erroring. This means the type would need to exist within a nullable type. But, this then means that it would be literally impossible to use these types in nested contexts without editing the code to put them in nullable wrapper types (like std::optional). This is because C++ can do things at compile time that we simply cannot do at runtime while parsing JSON.

In summary, a generic solution to this problem is extremely hard. If you need const fields in structs that are constructed from JSON, then first parse into types for the input arguments and then parse into the type that has const fields. But, I tend to see const fields as an anti-pattern in most use cases.

[WanZhiQiu-ac]

Thank you for your quick and enthusiastic response! Now I fully understand!