Generic supported concepts

[stephenberry]

The format specific concepts like: read_json_supported and write_beve_supported added extra boilerplate and did not allow custom formats. This change removes these non-generic functions and simply uses:

template <uint32_t Format, class T>
concept write_supported = requires { detail::to<Format, std::remove_cvref_t<T>>{}; };

template <uint32_t Format, class T>
concept read_supported = requires { detail::from<Format, std::remove_cvref_t<T>>{}; };

This more generic solution simplifies the code and makes adding new formats cleaner and possible for users without needing to modify the main Glaze repository.

Requested in #1619, but also noticed when beginning to add TOML that this approach is bad, especially as the number of formats grows.

[stephenberry]

@arturbac, This is a breaking change that will effect simple_enum. I intend to release this in v5.0.0.

Do you have additional thoughts on this change?
I plan to the remove the detail:: in the namespace for to/from specializations as well in v5.0.0. I'll do that in a follow on pull request.

[arturbac]

I looked at it, I was using those concepts and I will remove them from simple_enum header and move use to unit tests.
So add pls feature test macro only.
As i understand I'll have to add only conditional test on this feature test macro like below in unit tests...
Not a problem at all, thx for info

#ifndef glz_feature_xxxx
static_assert(glz::read_json_supported<test_enum_e>);
static_assert(glz::write_json_supported<test_enum_e>);
#else
static_assert(glz::read_supported<glz::JSON,test_enum_e>);
static_assert(glz::write_supported<glz::JSON,test_enum_e>);
#endif

[arturbac]

My taughts:
to/from specializations in simple enum are generic .

namespace glz::detail
  {
template<simple_enum::bounded_enum enumeration_type>
#ifdef glaze_v3_5_0_to_from
struct from<glz::JSON, enumeration_type>
#else
struct from_json<enumeration_type>
#endif
  {
  template<auto Opts, typename... Args>
    requires simple_enum::bounded_enum<enumeration_type>
  static void op(enumeration_type & arg, is_context auto && ctx, Args &&... args)
    {
    std::string_view value;
#ifdef glaze_v3_5_0_to_from
    read<glz::JSON>::op<Opts>(value, ctx, args...);
#else
    read<glz::json>::op<Opts>(value, ctx, args...);
#endif
    if(bool(ctx.error)) [[unlikely]]
      return;

    simple_enum::expected<enumeration_type, simple_enum::enum_cast_error> res{simple_enum::enum_cast<enumeration_type>(value
    )};
    if(!res.has_value()) [[unlikely]]
      {
      ctx.error = error_code::syntax_error;
      return;
      }
    arg = res.value();
    }
  };

So actually when You plan to remove detail all I have to do is to remove namespace scope and use namespace prefix dependant on feature test macro

#ifdef glz_feature_xxx....
namespace glz_spec_namespace = glz::detail;
#else
namespace glz_spec_namespace = glz;
#endif
template<simple_enum::bounded_enum enumeration_type>
#ifdef glaze_v3_5_0_to_from
struct glz_spec_namespace::from<glz::JSON, enumeration_type>
#else
struct glz_spec_namespace::from_json<enumeration_type>
#endif
  {

[arturbac]

Give me names of feature test macros and I'll blind implement those changes, for You in advance.

[stephenberry]

@arturbac, Sweet! The feature test macro glaze_v5_0_0_generic_supported has been added to indicate the generic write_supported and read_supported concepts.