Maybe only somewhat related, but I remember that we actually agreed on replicating the namespaces according the folder structure in which the classes are defined. That is to say, that instead of forwarding the namespaces, we should maybe in a follow-up PR remove the namespaces.

I dug up the conversation:

[wjwwood] So, +1 for a namespace per folder and not for a namespace per folder and file?

[Karsten1987] yes, that's correct.

[dirk-thomas] I agree[...] The namespace hierarchy should follow the folder hierarchy. Since we usually put one class into one file I don't think the file needs its own namespace. With that it should be straight forward to find the code of any type.

So it seems you are right @Karsten1987 that that was the conclusion, and that we should remove this namespaces.

I created this PR for the use case ros2/demos#199, so that demos wouldn't use the sub namespaces. That's something that we want to promote in our demos regardless, so I will merge this to support the demos, and then when we find time we should be safe to remove the namespaces from these classes without impacting the demos.
User code using the namespaced classes will break when we remove them so we should aim to do that by the release

+1 for merging this in order to fix the calling code and then get to removing the namespaces in rclcpp if we have time to do so.

Btw, a slightly less aggressive thing to do for the longer namespaces in rclcpp (e.g. rclcpp::node::Node versus rclcpp::Node) is to invert the current case (change class to be rclcpp::Node and typedef to point to rclcpp::node::Node) and then deprecate the typedef's (which you can now do portably in C++14 😁), with the [[deprecated("message")]] attribute specifier syntax:

http://en.cppreference.com/w/cpp/language/attributes
http://josephmansfield.uk/articles/marking-deprecated-c++14.html

It's super neat.

that's a good idea because there will definitely be code that will break if we flatout remove the namespace