Idea for Opts strong typing and easing of use

[arturbac]

It should work something like this

enum struct format {   json,   csv };
enum struct comments : bool {   no,   yes };


//---------------------- C++20 Version ----------------------

struct opts_cxx20 
   {
    format format_{format::json};
    comments comments_{};
    error_on_unknown_keys error_on_unknown_keys_{};
    
    constexpr opts_cxx20() = default;

    template<typename... Args>
    constexpr opts_cxx20(Args... args) {    (set(args), ...);   }

private:
    constexpr void set(format f) {   format_ = f;  }
    constexpr void set(comments c) {  comments_ = c;  }
    constexpr void set(error_on_unknown_keys e) {   error_on_unknown_keys_ = e;   }
   };

//---------------------- C++17 Version ----------------------

struct opts_cxx17 
   {
    format format_{format::json};
    comments comments_{comments::no};
    error_on_unknown_keys error_on_unknown_keys_{};
    
    constexpr opts_cxx17() = default;

    template<typename... Args>
    constexpr opts_cxx17(Args... args) {  set(args...);  }

private:
    void set() {}

    template<typename T, typename... Args>
    constexpr void set(T first, Args... args) {
        if constexpr (std::is_same_v<std::decay_t<T>, format>) {
            format_ = first;
        } else if constexpr (std::is_same_v<std::decay_t<T>, comments>) {
            comments_ = first;
        } else if constexpr (std::is_same_v<std::decay_t<T>, error_on_unknown_keys>) {
            error_on_unknown_keys_ = first;
        }
        set(args...); // recurse with remaining arguments
    }
};

//---------------------- Example Usage ----------------------

    glz::read_as<opts_cxx20{}>();
    glz::read_as<opts_cxx17{}>();

    glz::read_as<opts_cxx20{format::json}>();
    glz::read_as<opts_cxx17{format::json}>();

    glz::read_as<opts_cxx20{comments::yes}>();
    glz::read_as<opts_cxx17{comments::yes}>();

    glz::read_as<opts_cxx20{error_on_unknown_keys::yes}>(); 
    glz::read_as<opts_cxx17{error_on_unknown_keys::yes}>(); 
    
    glz::read_as<opts_cxx20{format::csv, comments::yes}>();
    glz::read_as<opts_cxx17{format::csv, comments::yes}>();

    glz::read_as<opts_cxx20{comments::no, format::csv}>();
    glz::read_as<opts_cxx17{comments::no, format::csv}>();
    
    glz::read_as<opts_cxx20{format::json, comments::yes, error_on_unknown_keys::yes}>(); 
    glz::read_as<opts_cxx17{format::json, comments::yes, error_on_unknown_keys::yes}>(); 

    glz::read_as<opts_cxx20{error_on_unknown_keys::no, format::csv, comments::no}>(); 
    glz::read_as<opts_cxx17{error_on_unknown_keys::no, format::csv, comments::no}>(); 

 // etc any combination ..

[arturbac]

I was constructing glz::read_as expression and got that idea so fast typed it for You.

[arturbac]

I posted it because it is annoying to work with field initializers, i have to look at original order to have correct code

static constexpr glz::opts default_json_parse_opts{
  .skip_null_members = false, 
  .error_on_unknown_keys = false};

 ISO C++ requires field designators to be specified in declaration order; field 'skip_null_members' will be initialized after field 'error_on_unknown_keys' [-Wreorder-init-list]

[stephenberry]

I like this idea. Another idea I've been considering is bit packing booleans in a uint64_t. So you can combine options like json | prettify | error_on_unknown_keys

The sequence doesn't matter, but the downsides are that this only works with booleans and we'd have to reword the options such that the default value of all options is false.

A benefit of this approach is that compilation errors are shorter because the compiler will display one integer for up to 64 booleans.

I just wanted to put this out as an alternative idea, but I think I prefer your approach. I do expect change how options are handled in the future, I just want to carefully consider various solutions before making a major API change.

[arturbac]

struct opts_cxx20
  {
  uint64_t flags_{static_cast<uint64_t>(format::json)};

  constexpr opts_cxx20() = default;

  template<typename Enum>
    requires std::is_enum_v<Enum> 
  constexpr void set(Enum e)
    {
    if (e == comments::enabled) {
            flags_ |= to_underlying(e);
        } else {
            flags_ &= ~to_underlying(comments::enabled);
        }
    }

  template<typename Enum>
  constexpr Enum get() const
    {
    if constexpr(std::is_same_v<Enum, format>)
      return (flags_ & static_cast<uint64_t>(format::json)) ? format::json : format::none; // handle csv as well
    else
      return (flags_ & static_cast<uint64_t>(Enum::enabled)) ? Enum::enabled : Enum::disabled;
    }
  };

[stephenberry]

Yeah, this is a good idea.

[arturbac]

of course

enum class format : uint64_t
  {
  none = 0,
  json = 1ull << 0,
  csv = 1ull << 1,
  };

enum class comments : uint64_t
  {
  disabled = 0,
  enabled = 1ull << 2,
  };

enum class error_on_unknown_keys : uint64_t
  {
  disabled = 0,
  enabled = 1ull << 3,
  };

[stephenberry]

I like this idea of packing everything into a uint64_t.

[arturbac]

Yea me too ;-), I have to make universal template from this for myself, just by using type list with concept restriction to enum and then use like, This would be quite useful mask like use with strong typing safety.

using opts_type_list = metatests::type_list<format, comments, error_on_unknown_keys>;
and add static assert validation if enums have underlying properly incremented ..

[stephenberry]

I really like the strong typing.

[arturbac]

thats nice.
I was thinking You don't need to even break backward compatbility in API ( in ABI You have)
You can make something like

namespace glz
  {
struct opts_t
  {
  constexpr opts_t() = default;
  };

inline namespace v2
  {
  struct opts2_t
    {
    constexpr opts2_t(glz::opts_t const &) noexcept
      {
      }

    };
  }  // namespace v2
  }  // namespace glz

[stephenberry]

I just thought of a perhaps even better approach. Say we use a std::tuple of strongly typed option within glz::opts, we could then build concepts to check whether glz::opts contains a particular option type.

glz::opts{ format::json, comments::yes }

This would store a std::tuple<format, comments>, and we could check with C++20 concepts whether the tuple contains various options. If other options are not set, then the default behavior is used.

The benefit of this approach is that our glz::opts struct only contains the options that we designate. Any default options won't exist in the template and therefore won't show up in compilation errors.

I feel like this would provide the cleanest solution. The only worry I have is if the additional type searching will have an impact on compile times. But, I wouldn't think it would be significant.

[arturbac]

compared to struct with just 1 uint64 it would be significant i think, but You can check with -ftime-trace on clang

[arturbac]

I've learned during my simple_enum project when did analysis with -ftime-trace that anything that involves template processing significantly impacts compile time even such case like in function for loop is much faster for compilation than transform or pointer arithmetic is much faster than std::distance as every template needs to be processed and instantiated while primitive ops are just executed. So if You want fast compile times for compile time processing always reduce template usage within that code to minimum. So If You can remove function call and template usage always do that for consteval for fast compile times.

[stephenberry]

Thanks, that is helpful insight. I've seen similar when profiling. I'm thinking bit packing all Booleans into a uint64_t for the non-user facing structure is the way to go. And, I'll leave options that require state within the structure so that it doesn't require additional concepts or template meta programming.