For the functions in parameter.h, I think you should consider type erasing the set and get functions. For example:

rcl_ret_t
rcl_parameter_set_integer(
  void * parameter,
  rcl_parameter_type_support_t * ts,
  const char * parameter_name,
  int value);

Where the rcl_parameter_type_support_t struct would look like this:

typedef struct rcl_parameter_type_support_t
{
  rcl_ret_t (*set_integer) (void * parameter, const char * name, int value);
  rcl_ret_t (*set_double) (void * parameter, const char * name, double value);
  // And so on...
} rcl_parameter_type_support_t;

There would be a version of this structure for each language supported and could live in a static (not generated) header in the rcl_interfaces package.

What this lets you do is use either C or C++ versions of the Parameter messages, for example C++:

#include <rcl_interfaces/msg/Parameter.hpp>
#include <rcl_interfaces/cpp/type_support.hpp>

rcl_interfaces::msg::Parameter param;
rcl_parameter_set_integer(
  &param,
  rcl_interfaces::get_cpp_parameter_type_support(),
  "foo", 42);

And the same for C using the same rcl_parameter* functions:

#include <rcl_interfaces/msg/Parameter.hpp>
#include <rcl_interfaces/c/type_support.h>

rcl_interfaces__msg__Parameter param;
rcl_parameter_set_integer(
  &param,
  rcl_interfaces_get_c_parameter_type_support(),
  "foo", 42);

And in the rcl_parameter_set_integer function you'd do something like this:

rcl_ret_t
rcl_parameter_set_integer(
  void * param,
  rcl_parameter_type_support_t * ts,
  const char * name,
  int value)
{
  return ts->set_integer(param, name, value);
}

This is all sort of roundabout, but allows you to add new language types (maybe PyObj * for Python or Local<Object> for NodeJS) without modifying rcl's API. The alternative is to unroll this and have get_int/set_int for functions in rcl for each supported language. In this pr only C is support, but you'd at least need to expand that to include C++ I think.

I suppose it's also worth taking a step back to consider if it is necessary to support more than just C messages in this parameter API. I don't have a high enough level view yet to say one way or the other.

For the functions in parameter.h and my last comment those could almost just go into rcl_interfaces completely, since they are just operations on the data structures themselves.

However, I think my above argument about using type erasure and type support structures to delegate work for different types applies more to functions like this:

RCL_PUBLIC
RCL_WARN_UNUSED
rcl_ret_t
rcl_parameter_client_take_set_response(
  const rcl_parameter_client_t * parameter_client,
  rmw_request_id_t * request_header,
  rcl_interfaces__msg__SetParametersResult__Array * set_parameters_result);

This function only supports the C type, and as you mentioned offline, it would be nice to use this interface in rclcpp with the C++ version of the parameter messages. You could imagine something more like this:

RCL_PUBLIC
RCL_WARN_UNUSED
rcl_ret_t
rcl_parameter_client_take_set_response(
  const rcl_parameter_client_t * parameter_client,
  rmw_request_id_t * request_header,
  void * set_parameters_result,
  rcl_message_type_support_t * set_parameters_result_ts);

Not sure about the types and stuff, but you get the idea. In this way these functions would emulate the underlying functions like publish, take, send_request, take_response, and so on.

Ok, I've finished my first review. I tried to give some useful feedback on any questions I saw and raise questions where I didn't understand, but now I'm just hoping it was more help than hindrance 😄.

bf05549 will ignore the parameters test for Connext Dynamic. With the fix_cpp_convert branches the test should pass for other middlewares.

Closing, as it's a bit outdated (same as ros2/rclcpp#276 (comment)).