Imagine that we would like to have multiple server parameters which have some shared specialized behavior. This came up on the query team in the context of SERVER-62797: we want many of the runtime-configurable server parameters declared in query_knobs.idl to flush the SBE plan cache on update. Furthermore, we want to make it unlikely that future engineers would forget to consider whether or not the SBE plan cache needs to be flushed when implementing a new IDL-generated server parameter, as I assume that this typically happens via copy-paste.

My first thought for how to achieve this would be to use the cpp_class option offered by the IDL for specialized server parameters. By default, the IDL will generate a new class for each parameter which inherits from IDLServerParameterWithStorage. However, if IDLServerParameterWithStorage does not serve your needs, you can specify cpp_class in order to add some specialized behavior associated with setting or updating the server parameter.

So I want to use the IDL to declare multiple server parameters which will both be instances of the same class. Something like this:

global:
  cpp_namespace: "mongo"

server_parameters:

  specializedKnobOne:
    description: "A parameter named 'specializedKnobOne' which is an instance of the class
    'SpecializedDemo'."
    set_at: [ startup, runtime ]
    cpp_class: SpecializedDemo

  specializedKnobTwo:
    description: "A parameter named 'specializedKnobTwo' which is an instance of the class
    'SpecializedDemo'."
    set_at: [ startup, runtime ]
    cpp_class: SpecializedDemo

However, this does not work with the current IDL. The IDL will generate two declarations of a class called SpecializedDemo, resulting in a compiler error like this:

In file included from build/opt/mongo/idl/cpp_class_demo_gen.cpp:9:
build/opt/mongo/idl/cpp_class_demo_gen.h:40:7: error: redefinition of 'SpecializedDemo'
class SpecializedDemo : public ServerParameter {
      ^

Instead, I would like to instruct the IDL to register a specialized parameter with a given name which is an instance of a particular class. For instance, the query team could implement a special server parameter class like QueryKnob<T, ShouldFlushCache> and register instances that have the ShouldFlushCache template parameter set to either true or false, depending on the meaning of the server parameter. Presumably QueryKnob would derive from IDLServerParameterWithStorage, just like the IDL-generated classes. The only responsibility of the IDL would be to generate the code to instantiate the server parameter and register it during process initialization; the actual behavior of the server parameter would be written in C++.

This could either be a new feature which lives alongside cpp_class, or the work for this ticket could be to change cpp_class to behave as described above. I'm not sure which is easier/better.