Glaze v5 Breaking Change Proposals

[stephenberry]

This discussion is to provide a space for writing down API breaking changes for Glaze version 5 that would help bring more clarity to the library.

[stephenberry]

Remove glz::detail namespace around to/from specializations

The to/from specializations are used to write custom serialization code. I feel like the APIs are formalized now and the to/from specialization should be moved out of the detail namespace. This will make C++20 modules export definitions make more sense, as they won't have to be applied to all these detail structs.

[arturbac]

You can add support for ADL functions along with old detail::to/from
In simple enum I support both for declaring bounds on enum.
This is very comfortable in situation when You specialize support for You custom/strong type.
Then instead of declaring something in glz:: namespace splitting Your type namespace like

namespace decl
{
 struct my_type{};
} 
template<>
struct glz::from<decl::my_type>{}
namespace decl
{
next code
}

You just declare ADL in the same namespace as Your strong type.

namespace decl
{
struct my_type{};
auto glz_from_op( my_type & ) -> required_return_type;
}

All You need to add is just add like

namespace glz
{
template<typename T>
concept adl_from_support = rquires(T const & v)
{
  { glz_from_op(v) } -> std::same_as< required_return_type>;
};
template<adl_from_support T>
struct from<JSON, T> { ... };
}

Such adl option would be very comfortable for user single/strong type use cases (not for simple_enum)

[fregate]

Change options.

1. Separate options for each format. At this moment, options mostly describe json format (num as string, boolean as number, null terminated, prettify, and so on). For BEVE and others (further) formats it is not relevant. So proposal to separate options for each format. It can be done with concepts like

template <typename T>
concept opt_t = requires std::is_integral_v<T::format>;

template <typename T>
concept json_opts_t = opt_t<T> and requires {
   requires std::is_boolean_v<T::null_terminated>;
   // other mandatory fields checks
}

template <typename T>
concept beve_opts_t = opt_t<T> and requires {
   requires ... // check mandatory fields
}

In this case you can even create concept for common_beve_json_opts_t which can handle and check common options for beve_to_json for example.
Also this separation can be useful for wrappers in my second proposal

2. Options per glz::meta basis. Right now you can override default options in wrappers field by field. Sometimes it can not so easy to define every field in glz::object. Or if some option is format specific like csv.layout or float_precision. So if you set some meta-based options its override defaults in read/write options and can be override in field wrappers as well.

struct my_struct {
    double field;
    struct meta {
       static csv_options opts{.layout = 1, .float_precision = float16};
    }
};

And this will apply only for csv format, because json_option_t can't fit it and won't use. But this point not, because .float_precision is valid for csv and json for example and can be used in both formats.
Or you set options in this way:

struct my_struct {
    double field;
    struct meta {
       static uint8_t layout = 1;
       static float_precition_enum float_precision = float16;
    }
};

And some big template magic I guess to handle this

[stephenberry]

We need to separate options from the meta information, because the meta information tells us how to handle keys and types, but we want to be able to use different options for the same struct.

I totally agree with the idea of using concepts to check for fields within an option structure. This way option structures can just contain the options that are pertinent, and if a field does not exist then we assume the default behavior for that option. Using C++20 concepts makes this compile time efficient as well.

Once we get reflection in C++26 we can take this a step further and generate a complete options structure based on the options that we want. Currently, we need to build out a struct of the particular option fields that the user cares about.