Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-86499

Consider generating "apply" method from IDL

    • Type: Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Service Arch

      Some users of types generated from IDL may wish to generically check properties of all fields present. For example, for types composed of optional values it may be useful to be able to check that all optionals are empty/in a default state.

      Checking this externally is trivial, but requires special care to ensure the caller is updated if the IDL changes in the future (e.g., static_assert on the number of fields).

      Given _gen files are already generated from IDL, it would be straightforward to provide an "apply" method -

      // Generated from IDL.
      auto apply(const auto& callback) {
          callback(field1);
          callback(field2);
          callback(field3);
      }
      ...
      // Usage.
      foo.apply([](const auto& value){/*...*/});
      

      Alternative providing the fields as a parameter pack:

      // Generated from IDL.
      auto apply(const auto& callback) {
          callback(field1, field2, field3);
      }
      ...
      // Usage.
      foo.apply([](const auto&... value){/*...*/});
      

      Or as_tuple could be provided -

      // Generated from IDL.
      auto as_tuple() {
          return std::forward_as_tuple(field1, field2, field3);
      }
      ...
      // Usage.
      std::apply([](const auto&... f) {/* some fold expression */}, foo.as_tuple());
      /// E.g.,
      std::apply([](const auto&... f) {return (!f.has_value() && ...);}, foo.as_tuple());
      

      Any such approach would simplify checking properties of all fields, and safely supports future changes to the IDL - either the callback already handles the new type, or compilation fails.


      A specific example of the utility of this would be QuerySettings. It is composed of optional fields, and we currently check "manually" that those fields are all nullopts to decide if a settings object is empty. Without additional care, fields added in the future would not be accounted for. In this case, this can be accounted for with a static_assert on the number of fields. However, either proposed solution would also make these usecases more concise.

            Assignee:
            backlog-server-servicearch [DO NOT USE] Backlog - Service Architecture
            Reporter:
            james.harrison@mongodb.com James Harrison
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: