[ros-users] [Discourse.ros.org] [Next Generation ROS] Optional Fields in Message

[Geoffviola]

I'm have trouble coming up with a good pub/sub use case for optional. In my example, Instead of a gyro driver producing an IMU message, it probably makes more sense to create a converter. Maybe, type masquarading and an ease of building small message converters has more value right now. Type masquerading is already on the roadmap: https://github.com/ros2/ros2/wiki/Roadmap.

I agree that remote function calls could use an optional field. Remote function calls are less common.

The protobuf history is interesting. I didn't really get their problem. It seemed to be a testing problem, which they didn't address. In the Cap'n Proto FAQ, the author mentioned protobuf 2's required field caused parsing failures when that part of the message definition was modified. DDS is strict on message types as well and will not allow reading part of a message. So the main point seems less relevant here.

There are a lot of ways to implement optional. Mathematically, setting the covariance to 0 may work if it is a final output; but it will not work if that data needs to be fused. This post is about treating optional as a first class message feature so that the interface is explicit. When it is explicit, the user is more likely to deal with it not being set.

As a little bit of context, my main motivation for proposing this feature was this talk called '
CppCon 2016: Ben Deane Using Types Effectively"
' at https://www.youtube.com/watch?v=ojZbFIQSdl8&t=2753s. The presenter argues why C++17's std::optional and std::variant are fundamental to types. I thought it would apply to ROS messages as well. I'd argue that we should add something like variant, but I don't quite understand it yet.






---
[Visit Topic](https://discourse.ros.org/t/optional-fields-in-message/991/13) or reply to this email to respond.