[boost] Re: BOOST_STATIC_ASSERT frowned up by core users

Am 23.10.25 um 09:55 schrieb Peter Dimov via Boost:
>> 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.
I agree to this:
1. "DETAIL" makes sure it won't be used by users (we care about)
2. Documentation would make it look official/to be used outside of 
Boost.Core.
But see below
> 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.
So your plan is to remove any references to Boost.StaticAssert from 
Boost.Core?
However I still see `#include <boost/static_assert.hpp>` although only 
in the tests.

Moreover the tests define yet another `STATIC_ASSERT` macro in multiple 
test files.

If you defined BOOST_CORE_STATIC_ASSERT for this reason then it should 
be always used and all references to Boost.StaticAssert be removed at 
the same time.Otherwise the benefit is rather limited.

> 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?
I was just about to write that exact argument:

Having BOOST_CORE_STATIC_ASSERT appear in other libraries' public 
headers will cause confusion.


The boost::core::string_view is a different case because it is a) large 
and b) provides more features than the boost::string_view
The latter is a separate issue.


I'd really like to see BOOST_ASSERT in Config and have 
Boost.StaticAssert just include that header.
Either we want to fine-grained organisation of parts and leave it in its 
own library, or we want no duplication.
Either way we should act consistently to that even if that involves 
cloning another, small library. With --depth=1 this should be rather fast.


Alex