Opinions on merging Assert, StaticAssert, ThrowException into Core
Recently Core grew with additional dependencies on StaticAssert (in 1.76) and ThrowException (in the next release), previously it was only depending on Assert and Config. That made a lot of libraries checkout the same four repositories, three of them containing only a few headers. Merging into a single dependency will affect mostly positive about 100 libraries and negative 1: StlInterfaces (depends on Assert, and will on Core). Please leave a comment at https://github.com/boostorg/core/issues/97 if you think it is a good idea, or have concerns against doing that.
Nikita Kniazev wrote:
Recently Core grew with additional dependencies on StaticAssert (in 1.76) and ThrowException (in the next release), previously it was only depending on Assert and Config. That made a lot of libraries checkout the same four repositories, three of them containing only a few headers. Merging into a single dependency will affect mostly positive about 100 libraries and negative 1: StlInterfaces (depends on Assert, and will on Core).
Please leave a comment at https://github.com/boostorg/core/issues/97 if you think it is a good idea, or have concerns against doing that.
I prefer keeping this discussion here on the list, rather than in an issue, so please reply here instead if you have an opinion. :-) The proposal is: * Merge Assert into Core * Merge StaticAssert into Core * Merge ThrowException into Core Each of these may be done or not. We also have an additional option of * Merge StaticAssert into Assert if we decide not to do the above.
On Sat, Oct 16, 2021 at 1:11 PM Peter Dimov wrote:
I prefer keeping this discussion here on the list, rather than in an issue, so please reply here instead if you have an opinion. :-)
The proposal is:
* Merge Assert into Core * Merge StaticAssert into Core * Merge ThrowException into Core
I'm not in favor of any of the above. There are no dependency cycles to break by doing this, and I prefer that we have facilities in separate repositories. Someone might want Assert and not anything else in Core. Someone else might want StaticAssert and not Assert or anything else in Core. I have no problems with Core taking on a new dependency on ThrowException although perhaps this dependency could be avoided too via: #if defined(BOOST_NO_EXCEPTIONS) BOOST_NORETURN void throw_exception(const std::exception&); #endif Glen
On 10/16/21 9:18 PM, Glen Fernandes via Boost wrote:
On Sat, Oct 16, 2021 at 1:11 PM Peter Dimov wrote:
I prefer keeping this discussion here on the list, rather than in an issue, so please reply here instead if you have an opinion. :-)
The proposal is:
* Merge Assert into Core * Merge StaticAssert into Core * Merge ThrowException into Core
I'm not in favor of any of the above. There are no dependency cycles to break by doing this, and I prefer that we have facilities in separate repositories.
Someone might want Assert and not anything else in Core. Someone else might want StaticAssert and not Assert or anything else in Core.
I have no problems with Core taking on a new dependency on ThrowException although perhaps this dependency could be avoided too via:
#if defined(BOOST_NO_EXCEPTIONS) BOOST_NORETURN void throw_exception(const std::exception&); #endif
I agree. Generally, I'd prefer if we made Boost more granular and less coarse-grained. This also protects from feature creep in Boost.Core. Merging StaticAssert into Assert might be ok though. Those are basically two sides of the same coin.
On Sat, Oct 16, 2021 at 2:30 PM Andrey Semashev wrote:
On 10/16/21 9:18 PM, Glen Fernandes via Boost wrote:
On Sat, Oct 16, 2021 at 1:11 PM Peter Dimov wrote:
I prefer keeping this discussion here on the list, rather than in an issue, so please reply here instead if you have an opinion. :-)
The proposal is:
* Merge Assert into Core * Merge StaticAssert into Core * Merge ThrowException into Core
I'm not in favor of any of the above. There are no dependency cycles to break by doing this, and I prefer that we have facilities in separate repositories.
Someone might want Assert and not anything else in Core. Someone else might want StaticAssert and not Assert or anything else in Core.
I have no problems with Core taking on a new dependency on ThrowException although perhaps this dependency could be avoided too via:
#if defined(BOOST_NO_EXCEPTIONS) BOOST_NORETURN void throw_exception(const std::exception&); #endif
I agree. Generally, I'd prefer if we made Boost more granular and less coarse-grained. This also protects from feature creep in Boost.Core.
Note that such a merge wouldn't just affect StlInterfaces, it would also affect: * TypeTraits * Variant2 * ConceptCheck * System * TypeOf * Atomic * Crc * Pool ... and more. None of the above depend on Core right now. They would after such a merge. Users that consume any of these libraries don't need anything else in Core. Glen
Glen Fernandes wrote:
I have no problems with Core taking on a new dependency on ThrowException although perhaps this dependency could be avoided too via:
#if defined(BOOST_NO_EXCEPTIONS) BOOST_NORETURN void throw_exception(const std::exception&); #endif
It could, but using the "proper" boost::throw_exception is better because it adds a source location (and boost::exception_ptr support under C++03) to the exception.
On 16/10/2021 18:10, Peter Dimov via Boost wrote:
Nikita Kniazev wrote:
Recently Core grew with additional dependencies on StaticAssert (in 1.76) and ThrowException (in the next release), previously it was only depending on Assert and Config. That made a lot of libraries checkout the same four repositories, three of them containing only a few headers. Merging into a single dependency will affect mostly positive about 100 libraries and negative 1: StlInterfaces (depends on Assert, and will on Core).
Please leave a comment at https://github.com/boostorg/core/issues/97 if you think it is a good idea, or have concerns against doing that. I prefer keeping this discussion here on the list, rather than in an issue, so please reply here instead if you have an opinion. :-)
The proposal is:
* Merge Assert into Core * Merge StaticAssert into Core
This is fine by me, I imagine that Boost.StaticAssert is rapidly becoming obsolete anyway? John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Sat, Oct 16, 2021 at 2:19 PM John Maddock wrote:
This is fine by me, I imagine that Boost.StaticAssert is rapidly becoming obsolete anyway?
Not everyone is on C++17 to use static_assert(expr), so even C++11 and C++14 Boost libraries (and some Boost users) choose BOOST_STATIC_ASSERT(expr) over having to static_assert(expr, "expr") etc. Glen
Glen Fernandes wrote:
On Sat, Oct 16, 2021 at 2:19 PM John Maddock wrote:
This is fine by me, I imagine that Boost.StaticAssert is rapidly becoming obsolete anyway?
Not everyone is on C++17 to use static_assert(expr), so even C++11 and C++14 Boost libraries (and some Boost users) choose BOOST_STATIC_ASSERT(expr) over having to static_assert(expr, "expr") etc.
That's true, but the implementation can be simplified considerably if C++11 can be assumed. :-)
On Sat, Oct 16, 2021 at 3:16 PM Peter Dimov wrote:
Glen Fernandes wrote:
On Sat, Oct 16, 2021 at 2:19 PM John Maddock wrote:
This is fine by me, I imagine that Boost.StaticAssert is rapidly becoming obsolete anyway?
Not everyone is on C++17 to use static_assert(expr), so even C++11 and C++14 Boost libraries (and some Boost users) choose BOOST_STATIC_ASSERT(expr) over having to static_assert(expr, "expr") etc.
That's true, but the implementation can be simplified considerably if C++11 can be assumed. :-)
No argument there. In some sense, we're in that happy place now already - i.e. it is simplified, when C++11 is assumed: #ifndef BOOST_NO_CXX11_STATIC_ASSERT # ifndef BOOST_NO_CXX11_VARIADIC_MACROS # define BOOST_STATIC_ASSERT( ... ) static_assert(__VA_ARGS__, #__VA_ARGS__) # else # define BOOST_STATIC_ASSERT( B ) static_assert(B, #B) # endif #else Everything after that #else is just padding bytes anyway. :) Glen
On Sat, Oct 16, 2021 at 9:48 AM Nikita Kniazev via Boost < boost@lists.boost.org> wrote:
Recently Core grew with additional dependencies on StaticAssert (in 1.76) and ThrowException (in the next release), previously it was only depending on Assert and Config. That made a lot of libraries checkout the same four repositories, three of them containing only a few headers. Merging into a single dependency will affect mostly positive about 100 libraries and negative 1: StlInterfaces (depends on Assert, and will on Core).
Such a refactor will affect user code not only Boost libraries. I don't know how much user code exists that depends on each individual repo, though IMO it's better to leave things as they are.
Emil Dotchevski wrote:
Such a refactor will affect user code not only Boost libraries. I don't know how much user code exists that depends on each individual repo, though IMO it's better to leave things as they are.
That's a good point. E.g. every CMake project that links to Boost::assert will be broken. There probably aren't that many yet though.
On Sat, Oct 16, 2021 at 8:51 PM Peter Dimov via Boost
Emil Dotchevski wrote:
Such a refactor will affect user code not only Boost libraries. I don't
know how
much user code exists that depends on each individual repo, though IMO it's better to leave things as they are.
That's a good point. E.g. every CMake project that links to Boost::assert will be broken. There probably aren't that many yet though.
If we're talking about CMake, it makes even less sense, since it clones and links things automatically. If anything, this allows us to adjust our preference towards more, not fewer modules.
participants (7)
-
Andrey Semashev -
Emil Dotchevski -
Glen Fernandes -
John Maddock -
Nikita Kniazev -
Peter Dimov -
Vinnie Falco