Repository navigation
Feature Request: Optional Attributes #850
Description
DDS supports the optional attribute in IDL 4.2 specification attribute section 8.3.1.3. In C++, now that we have C++17, we can use std::optional.
A prior dicussion is here: https://discourse.ros.org/t/optional-fields-in-message/991/16
Consider adding a @optional specifier to rosidl that translates to the DDS optional .
Amend the ROS 2 design documentation for Standardized Annotations to add optional:
https://design.ros2.org/articles/idl_interface_definition.html
It's supported by:
Workarounds: Bounded array with a max length of 1, but the syntax is funky.
Reacted by Loy van Beek, lin72h, Anthony Welte, Yukihiro Saito, Yifei Ma, Kotaro Yoshimoto and Raphael van Kempen
Activity
alsora commentedon Mar 6, 2025
Hi, we discussed this during the ROS waffle meeting and while we agree that this would be a useful feature, we also recognize that it will require a relatively large amount of work.
It would be great to get some support from the community.
Ryanf55 commentedon Mar 7, 2025
Thanks. If I end up getting time allocated at work, I'll request being assigned, but otherwise anyone is welcome.
Would you accept a merge with opt-in support of
@optionalif I got it working only with the following:We want this feature to integrate with a non-ROS-based software. The only incompatibility is the use of optional.
Getting this working on all RMW's and all languages is unlikely to be approved, but I could get a subset of the work approved.
ros-discourse commentedon Mar 25, 2025
This issue has been mentioned on ROS Discourse. There might be relevant details there:
https://discourse.ros.org/t/challenges-with-ros2-on-commercial-robots/42784/8
InvincibleRMC commentedon Jul 29, 2025
Hey, I'm interested in taking a stab at adding optional support at least in
rosidl_generator_cpp. One design question I have is should I add another class forOptionalintorosidl_parser.defintionor simply check whether the member has the optional annotation and update places that usemsg_type_to_cppto something likemember_to_cpp. Another is would the default forstd::optional<int>be0orstd::nullopt.Ryanf55 commentedon Jul 29, 2025
Nice!
According to RTI, by default, optional members should be unset, so not default initialized. So,
std::nullopt.https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/extensible_types_guide/extensible_types/Optional_Members.htm
By default optional members are unset (dds::core::optional<T>::has_value() is false).InvincibleRMC commentedon Aug 1, 2025
When updating the actual
.msg,.srv, or.actionfiles to support optional fields, would you prefer introducing a newoptionalkeyword before the type, using a question mark after the type (e.g.,char?for an optionalchar), or some other approach?christophebedard commentedon Aug 1, 2025
I think we should do
@optionalin ROSIDL (.msg/.srv/.action) like OMG IDL does. OMG IDL has other@annotations(e.g.,@key,@default,@verbatim) which ROSIDL could potentially also support, so@optionalwould be more IDL-y.Ryanf55 commentedon Aug 1, 2025
Agree
InvincibleRMC commentedon Aug 1, 2025
@christophebedard is there some generic rmw agnostic test set I can use for testing? Trying to determine if my serialization code actually works or is a lie.
christophebedard commentedon Aug 1, 2025
Something like the tests from the packages in this repo? https://github.com/ros2/system_tests
MiguelCompany commentedon Oct 31, 2025
@InvincibleRMC There is also https://github.com/ros2/rmw_implementation/tree/rolling/test_rmw_implementation