Overall this looks good. I'm a little worried about implicitly creating the executor inside. This is something we should review going forward. But we can use this for now.

+1

I've renamed ParameterListResult and ParameterSetResult to ListParametersResult and SetParametersResult respectively in ros2/rcl_interfaces#3

Currently the API uses multiple template specializations of get_value with different return types. So the user must always specify the template type. Do we want to provide methods which contain the type in the name (additionally or instead)? We might also consider the C-equivalent of this API - will parameters in C and C++ be completely different implementations?

Also I think we could still return const std::string & in the case of strings (#26 (comment)). I don't think that the template T prevents us from specializing it for const std::string &?

@dirk-thomas I've changed it so that the user only needs to pass the ParameterType value to get_value<> instead of using types.

I think this could be improved if we didn't require the storage to be a ParameterValue, which is completely an implementation detail. Then we could declare all the constructors as constexpr as well as get_type and it'll be less cumbersome:

auto value = p.get_value<p.get_type()>()

or we might even get rid of p.get_type and just use p.get_value

There's precedence in other API's for have something like .asString, .asInt, and .asDouble rather than .as<std::string>, .as<int64_t>, and .as<double>, especially when there are a finite set of options. I don't really mind one way or the other.

As for it being aligned with the style of the C api, I think it's fine if they are not one to one. If it makes more sense to use a template in the C++ and an expanded name in C that's fine. It can be made similar and familiar without being exactly the same.

+1 to as_string, as_int, etc. instead of templatized get_value

I've added the as_* versions of the get_value method, so when we reach a consensus I'll just remove the one that less popular. My vote goes for the as_* methods.