If that's the consensus, then sure, I'll delete static_assert.qbk and rename the macro to BOOST_CORE_DETAIL_STATIC_ASSERT.
Is it, though? I'd like to hear more opinions on this. To recap, the problem being solved is that Core should not depend on StaticAssert, because C++11 libraries that depend on Core and StaticAssert can't drop the dependency on StaticAssert even if they stop using BOOST_STATIC_ASSERT, as this just moves StaticAssert from a primary dependency to a secondary dependency. One common (and established) way of avoiding the dependency on StaticAssert is to create a library-private macro #define BOOST_LIBNAME_STATIC_ASSERT(...) \ static_assert(__VA_ARGS__, #__VA_ARGS__) Several libraries do this already, and others are going to. Core uses BOOST_STATIC_ASSERT in two places, bit.hpp and cmath.hpp (both of which I wrote.) So I applied the usual approach, defined a library-private macro BOOST_LIBNAME_STATIC_ASSERT, where LIBNAME is CORE, and switched bit.hpp and cmath.hpp to use it instead of including <boost/static_assert.hpp>. I then decided to document this macro, because I figured that the aforementioned libraries that already use Core and want to avoid <boost/static_assert.hpp> can just switch to the Core macro instead of defining their own. That's more convenient and avoids duplication. However, the counterargument to documenting the macro is that users will be confused upon encountering two public macros that do the exact same thing (BOOST_CORE_STATIC_ASSERT and BOOST_STATIC_ASSERT), and therefore it's better to leave the Core macro out of the documentation and not make it a public header. Opinions?