Add skip function for glz::meta to ignore members during write

[Yaraslaut]

To customize writing of custom types it may be more user friendly to provide a list of members to ignore instead of specialization of glz::meta this PR attempts to add such functionality

I marked it as a draft since implementation is not complete but would appreciate any feedback

[stephenberry]

Thanks for looking into this!

I'm really liking the new functional approach within glz::meta for these kinds of customizations.

Here is an example of the supported rename_key:

struct renamed_t {
    std::string first_name{};
    std::string last_name{};
    int age{};
};

template <>
struct glz::meta<renamed_t> {
    static constexpr std::string_view rename_key(const std::string_view key) {
        if (key == "first_name") {
            return "firstName";
        }
        else if (key == "last_name") {
            return "lastName";
        }
        return key; // Return unchanged for other keys
    }
};

I tend to think this would be a better approach for your goal, and would look like:

struct specify_only_skip_obj
 {
    int x{1};
    int y{2};
 };

template <>
struct glz::meta<specify_only_skip_obj > {
    static constexpr bool skip(const std::string_view key) {
        return key == "x"; // only skip the "x" key
    }
};

What do you think about this approach? It allows you to skip all keys that start with a specific character, or end with a particular extension, etc. It allows more customized skipping based on key names and keeps things in glz::meta so that it is easy to see manipulations on your type. This would only ever run at compile time.

[Yaraslaut]

Hi, thanks for the feedback, this is indeed much more flexible, will update pr accordingly

[stephenberry]

Cool, I would be happy to merge in a pull request that adds this skip support. I can also help as needed.

[stephenberry]

I cleaned up the code a little and added a check for whether the glz::meta has a skip within maybe_skipped. This constexpr branch already handled potential skipping so, the wrote_element bool code isn't needed.

I also updated the code to use reflect<T>::keys[I] for the names to skip. I'd like to get your opinion on this. This is the higher level name API that will provide names that have been changed via rename_key, so you would refer to what keys to skip based on their name in JSON rather than their C++ filed name. Is this the best approach? In one sense using reflect<T>::keys[I] is how the majority of the codebase works, and helps keep things consistent. But, if there is complex renaming, then maybe it would be nicer to base skip on the C++ field name?

[Yaraslaut]

Thanks for the update, I think that skipping based on the rename provided by the user is more expected than not, and this is more user facing since it some cases it might be more beneficial for user to rename there members

Looks like we can merge this one

[stephenberry]

Sweet! I'll merge it in, thanks for your contributions and feedback!

[scalpel4k]

@stephenberry is there the possibility to hook into the skip call also from a 'full' to/from custom serialization?

My problem is that I have fields that I can't mark optional and I need to inspect the field object before making the decision whether it can be skipped or not. And I also can't use the compile-time option skip_null_members.

thx Michi

[stephenberry]

@scalpel4k, I think you would have to implement checks for skipping within your custom to/from specializations. You can look how it is implemented in the JSON read.hpp and write.hpp.

For reading, it looks like this:

if constexpr (meta_has_skip<std::remove_cvref_t<T>>) {
    if constexpr (meta<std::remove_cvref_t<T>>::skip(Key, {glz::operation::parse})) {
       skip_value<JSON>::op<Opts>(ctx, it, end);
       if (bool(ctx.error)) [[unlikely]]
          return; // Propagate error from skip_value
       return;
    }
 }

The skip_value call will parse over the JSON value, skipping it, and allowing an immediate return because it has been handled.

[scalpel4k]

thanks for the hint, I'll have a look into it