With the current approach (which is the same in ROS 1 C++) the header files of messages, services, derived service messages (request and response) all share the same namespace with the package code.

• Placing the generated code of messages / services in a subfolder / subnamespace avoids collisions with other code in the package.
• Separating the headers for messages and services in separate subfolders / namespaces (e.g. msg and srv) avoids collisions between them. It allows to have an Empty.msg as well as an Empty.srv. This is closer to the ROS 1 Python naming scheme.
• The derived service messages types (request and response) should stay together with the services (and e.g. not go into the msg subfolder).
• To prevent collisions between service names and their derived service messages the request and response files must be constructed in either of the following two ways:
  • They are defined in a subnamespace named after the service (since it creates two additional namespaces per service I would suggest the next option).
  • They are being names with a suffix starting with _ (e.g. Foo_Request.h) which is not a valid message / service name.

Pros:

• No naming collisions between package code and generated code for messages / services, the subnamespaces msg and srv are reserved.
• No collisions between message and service names.
• No collision between service names and their derived request / response types.
• The change locations keep user code and generated message / service code nicely separated.

Cons:

• User land code has to include messages / services from a subfolder and use them with a subnamespace:

#include <my_interfaces/msg/Foo.hpp
my_interfaces::msg::Foo foo;

Theire are two more aspects I would like to address in the process of this refactoring:

• Currently the generated header files are using camel case for the filename. Should we change that to use lowercase + underscore instead? For the _Request suffix that would imply e.g. using a double underscore as a separator (to keep avoiding collisions).
• The generated C++ header are currently ending in .h. I would propose to change them to .hpp to be consistent with our guidelines.

@esteve @tfoote @wjwwood Please provide feedback before I start working on the necessary PRs.

• Update generated C code to drop -c suffix and apply the same naming rules as for C++ and only differentiate based on the extension.