+1 I would also appreciate support for optional fields in ROS2. The best use case I can currently think of is to get rid of the `geometry_msgs/FooWithCovariance` message types and merge them into one `geometry_msgs/Foo` message with an optional covariance field (not considering backwards compatibility in this case). A node that is only interested in the actual value and not in the covariance information would not need to implement different subscribers for the two types or apply shape shifting. Other tools like rviz could optionally visualize the covariance, if available. In general, having native optional field support in many cases removes the need to define different, but very similar messages and - depending on how the presence of optional fields is encoded in the wire format - can also help to reduce wire size because unavailable data does not have to be represented by a full 8-byte NaN double. Protobuf 2 also has [optional (an required) fields](https://developers.google.com/protocol-buffers/docs/proto#optional), but apparently this feature has been removed in [Protobuf 3](https://developers.google.com/protocol-buffers/docs/proto3) for a good reason... --- [Visit Topic](https://discourse.ros.org/t/optional-fields-in-message/991/4) or reply to this email to respond. If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates. ______________________________________________________________________________ ros-users mailing list ros-users@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-users Unsubscribe: