Description
From what I can find in the documentation on NodeInterfaces, the rclcpp::node_interfaces::detail::NodeInterfacesSupport class is meant to be specialized by users and thus is part of the public interface of rclcpp, however, it is part of the detail namespace explicitly called out as not public interface.
Since it is the only way to use the class with custom interfaces and is explicitly called out in the docs, I would assume it is part of the public interface. Should we maybe mark it more clearly on the rclcpp::node_interfaces::detail::NodeInterfacesSupport itself (both for users and future changes?).
I don't know if there is any other reason for it to be in the detail namespace. This functionality was added in #2041 and was like this from the beginning.
Motivation
Depending on implementation details of library is wrong, so we should be clear on whether this is public API or not.
Design / Implementation Considerations
I don't think it is feasible to change the namespace of the type, as that would break any existing users. The path of the header may be changed and the old one kept for compatibility if deemed necessary.
The most likely resolution I can think of is just an explicit note in the documentation that the class is part of the public API despite the namespace, so that both users and maintainers know, how to approach it.
Additional Information
No response
Description
From what I can find in the documentation on
NodeInterfaces, therclcpp::node_interfaces::detail::NodeInterfacesSupportclass is meant to be specialized by users and thus is part of the public interface of rclcpp, however, it is part of thedetailnamespace explicitly called out as not public interface.Since it is the only way to use the class with custom interfaces and is explicitly called out in the docs, I would assume it is part of the public interface. Should we maybe mark it more clearly on the
rclcpp::node_interfaces::detail::NodeInterfacesSupportitself (both for users and future changes?).I don't know if there is any other reason for it to be in the detail namespace. This functionality was added in #2041 and was like this from the beginning.
Motivation
Depending on implementation details of library is wrong, so we should be clear on whether this is public API or not.
Design / Implementation Considerations
I don't think it is feasible to change the namespace of the type, as that would break any existing users. The path of the header may be changed and the old one kept for compatibility if deemed necessary.
The most likely resolution I can think of is just an explicit note in the documentation that the class is part of the public API despite the namespace, so that both users and maintainers know, how to approach it.
Additional Information
No response