Ruben Perez wrote:
In the general case (when a header also defines macros), the public header will contain both
import boost.mp11;
and the part that defines the macros, which in Mp11's case is
#include
User code wouldn't need to know that in addition to the import, it also needs to include a separate macro header.
This assumes that macros are "standalone" and don't require including any stdlib headers. This is the case for mp11/version.hpp and lightweight test, but is not for Boost.Config or Boost.Charconv headers, for instance. These may require including <cstddef> or <cstdint> for macros, which need to happen before any import std. Wouldn't this cause trouble with your scheme?
Possibly, yes. If we want to keep the public headers usable in a module unit, we can't include <cstddef> there because it will introduce declarations. Although whether we need to keep the headers usable in a module unit is up for debate. Fixing this properly can only be done on the stdlib/implementation side.