The hal::make namespace is a code smell. It will make it possible to have definition errors when users do:
using namespace hal;
using namespace hal::make;
Even though this would be discouraged, it makes for a bit of a hard error to track down.
A reason for making this namespace was actually for documentation api code generation via Doxygen. Having a namespace meant that the code is grouped away from and separated from the hal namespace. This helps to not clutter the hal namespace but adds the issue above. An alternative is to simple alias make_<interface> functions from their native package namespace to the hal namespace. Like so:
namespace hal::foo {
class some_pwm_impl {
friend result<some_pwm_impl> make_pwm(/* ... */);
};
result<some_pwm_impl> make_pwm(/* ... */);
}
namespace hal {
using hal::foo::make_pwm;
}
This ensures that class implementations are in the package namespace, is clean and doesn't require complex forward declarations or complex friend namespace syntax.
The hal::make namespace is a code smell. It will make it possible to have definition errors when users do:
Even though this would be discouraged, it makes for a bit of a hard error to track down.
A reason for making this namespace was actually for documentation api code generation via Doxygen. Having a namespace meant that the code is grouped away from and separated from the
hal
namespace. This helps to not clutter the hal namespace but adds the issue above. An alternative is to simple aliasmake_<interface>
functions from their native package namespace to thehal
namespace. Like so:This ensures that class implementations are in the package namespace, is clean and doesn't require complex forward declarations or complex friend namespace syntax.