On 23 Oct 2025 04:16, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
Again, then move the macro into Core or Config.
Moving BOOST_STATIC_ASSERT to Config is a good solution. Once it's done, we can retire BOOST_CORE_STATIC_ASSERT. Until then, it's necessary.
No, as that keeps the BOOST_CORE_STATIC_ASSERT duplicate, and potentially allows users to depend on it, only then to be removed. Why do you want BOOST_CORE_STATIC_ASSERT right now? What is the urgency that you want to add it before moving BOOST_STATIC_ASSERT into Config?
I didn't see any benefits from not making it public. Libraries that already depend on Core can take advantage of it.
They currently either depend on StaticAssert or, as you say, define their own macros. Why can't they keep doing it while we're making the release and then merging StaticAssert into Config?
boost/static_assert.hpp has a lot of baggage that is probably all obsolete, so having the leaner Core implementation available to others will be a good way to test that hypothesis, which will be useful for when we decide to move BOOST_STATIC_ASSERT to Config.
I'd say, if you want to clean up the baggage then do it after merging into Config. That work is separate from dependency reduction.