On 23 Oct 2025 04:15, Vinnie Falco wrote:
On Wed, Oct 22, 2025 at 6:06 PM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Again, then move the macro into Core or Config
If we are to move the macro instead of adding a new one, then maybe the beginning of a release cycle is not the best time for it.
I agree. So for now, revert the addition of BOOST_CORE_STATIC_ASSERT. After the release, move BOOST_STATIC_ASSERT to Core or Config.
BTW, I don't find adding a small dependency such as StaticAssert as a problem, assuming I really need it and C++11 static_assert is somehow not acceptable.
If that works for you, by all means keep doing it. Yet a common complaint is that Boost libraries each have too many dependencies. This was known 6 years ago and hasn't change (and probably has gotten worse):
https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/ <https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/>
People will complain no matter what. People who view Boost as a single dependency will complain it's too heavy. People who consume select libraries will complain about too many dependencies. Duplicating code in libraries doesn't make either one group happy as libraries and Boost as a whole become more bloated. The first group gets a larger package, the second one doesn't save as much as they hoped by picking individual libraries. Just stop. Do what is reasonable from a sane user's and maintainer's perspective. A sane user doesn't want to have a dozen static_assert macros to choose from. A sane maintainer doesn't want to maintain that same dozen of macros. If someone has a problem with dependencies, let them solve that problem on their end. This doesn't mean we shouldn't try reducing dependencies where that actually matters and makes sense, though.
But I actually have a hard time seeing how C++11 static_assert wouldn't cut it to such a degree that I would go an extra mile to define my own macro.
DIfferent people see things differently. I for example, prefer the 1- argument static_assert because of two reasons
* It is consistent (no variation in the emitted diagnostic)
* I don't have to think about what string I want to put
I find that most of my static_asserts do have a message. Partly because I find it user-friendly, partly because it does make me think twice about what I'm actually requiring, at a high level. I also find that I often skip the message out of laziness or lack of time rather than because the message wouldn't make sense. But this is off topic and personal preference.