Nathan Wiebe Neufeldt

I put together a prototype of this feature [here](https://github.com/ros2/rclcpp/compare/16.0.3...nwn:rclcpp:nwn/async-actions) (based on `16.0.3` since I'm currently running Humble). The implementation wasn't too complex, and mainly involved splitting the logic from the...

@fujitatomoya I agree, we should use a consistent format across client libraries. Unfortunately, rclpy currently doesn't format goal IDs well either. For example, the rclpy action server prints them as...

@fujitatomoya @clalancette Are there any further concerns about this or action required to get this merged?

> @clalancette: My 2 cents is that we shouldn't take this PR until we can at least reasonably compile it (that is, we switch to C++20). Otherwise this is just...

> @nwn let me know if the message generator is in a more or less complete state and I'll split it off from this PR. Thanks for continuing the work...

> I'll start by reviewing the current state of the PR and see if I can identify anywhere that I can help, but if @nwn has any guidance on where...

In the interest of breaking this work into smaller pieces and also getting the message generation side merged sooner, I've split off all the `rosidl_{generator,runtime}_rs` changes into a separate PR,...

@Guelakais I assume we're only talking about the message types, since the top-level action type is an empty struct that's only useful as a generic type parameter. It's not useful...

@mxgrey > > Certain of these methods involve accessing timestamps and UUIDs in messages. To avoid adding a dependency in rosidl_runtime_rs on builtin_interfaces and unique_identifier_msgs, these are represented in a...

> I know this may be asking a lot for such complex message generation, but can you add some high level docs? @maspe36 I've added a short doc page under...