BOOST_STATIC_ASSERT frowned up by core users
If you use BOOST_STATIC_ASSERT and you also use Boost.Core, you can use BOOST_CORE_STATIC_ASSERT instead and save one dependency. Thanks
El 22/10/2025 a las 5:37, Vinnie Falco via Boost escribió:
If you use BOOST_STATIC_ASSERT and you also use Boost.Core, you can use BOOST_CORE_STATIC_ASSERT instead and save one dependency.
Thanks
Two questions: - Why isn't BOOST_STATIC_ASSERT added to Boost.Config just like boost/config/cstdint.hpp or boost/config/limits.hpp or boost/config/cxx11_char_types.hpp instead of adding it to core? Boost.StaticAssert could just forward Boost.Config's implementation to avoid breaking code. - Why isn't C++11's static_assert used versions used when BOOST_CXX_VERSION shows C++11 is supported? Best, Ion
On 22/10/2025 21:40, Ion Gaztañaga via Boost wrote:
El 22/10/2025 a las 5:37, Vinnie Falco via Boost escribió:
If you use BOOST_STATIC_ASSERT and you also use Boost.Core, you can use BOOST_CORE_STATIC_ASSERT instead and save one dependency.
Thanks
Two questions:
- Why isn't BOOST_STATIC_ASSERT added to Boost.Config just like boost/config/cstdint.hpp or boost/config/limits.hpp or boost/config/cxx11_char_types.hpp instead of adding it to core? Boost.StaticAssert could just forward Boost.Config's implementation to avoid breaking code.
- Why isn't C++11's static_assert used versions used when BOOST_CXX_VERSION shows C++11 is supported?
Indeed. And isn't core C++11 anyway, so we could just use a real static_assert rather than a macro? But for the avoidance of any doubt, I'm quite happy for StatcAssert to be moved to config. But I also don't see a single rather tiny header as some kind of massive dependency which needs to be avoided via code duplication. John.
John Maddock wrote:
And isn't core C++11 anyway, so we could just use a real static_assert rather than a macro?
Not yet.
But for the avoidance of any doubt, I'm quite happy for StatcAssert to be moved to config.
But I also don't see a single rather tiny header as some kind of massive dependency which needs to be avoided via code duplication.
It's not the tiny header, but that you need an entire repository for it.
Andrey Semashev wrote:
On 22 Oct 2025 06:37, Vinnie Falco via Boost wrote:
If you use BOOST_STATIC_ASSERT and you also use Boost.Core, you can use BOOST_CORE_STATIC_ASSERT instead and save one dependency.
Why do we keep adding this stuff to Core?? And even make it a public component, too?
To remove the dependency on StaticAssert.
On 23 Oct 2025 03:32, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
On 22 Oct 2025 06:37, Vinnie Falco via Boost wrote:
If you use BOOST_STATIC_ASSERT and you also use Boost.Core, you can use BOOST_CORE_STATIC_ASSERT instead and save one dependency.
Why do we keep adding this stuff to Core?? And even make it a public component, too?
To remove the dependency on StaticAssert.
I'm sorry, but this is just silly at this point. StaticAssert is even more lightweight than Core. If depending on it is a problem then how is it not a problem to depend on Core? And if you mean removing the dependency on it from Core, then why not merge StaticAssert into Core? Or into Config, which I think was suggested before? Or make it an internal implementation detail, if merging is not desirable for some reason? Why do we duplicate stuff in every library in the blind pursuit of reducing dependencies that doesn't bring any real benefits? How are users are supposed to know which alternative is the proper one? IMO, this component should be replaced with use of StaticAssert, which would in turn be merged in either Core or Config. Or, if not that, it should be made a private implementation detail of Core.
Andrey Semashev wrote:
On 23 Oct 2025 03:32, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
On 22 Oct 2025 06:37, Vinnie Falco via Boost wrote:
If you use BOOST_STATIC_ASSERT and you also use Boost.Core, you can use BOOST_CORE_STATIC_ASSERT instead and save one dependency.
Why do we keep adding this stuff to Core?? And even make it a public component, too?
To remove the dependency on StaticAssert.
I'm sorry, but this is just silly at this point.
No, it isn't silly at all. Silly is having a whole physical dependency on an entire repo just to have a one line macro. That's why C++11 libraries define their own instead of using StaticAssert. But then there's another silly thing. You define your own macro, but this just moves StaticAssert from a primary dependency to a secondary dependency because Core brings it in. We don't want silly things.
On 23 Oct 2025 03:51, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
On 23 Oct 2025 03:32, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
On 22 Oct 2025 06:37, Vinnie Falco via Boost wrote:
If you use BOOST_STATIC_ASSERT and you also use Boost.Core, you can use BOOST_CORE_STATIC_ASSERT instead and save one dependency.
Why do we keep adding this stuff to Core?? And even make it a public component, too?
To remove the dependency on StaticAssert.
I'm sorry, but this is just silly at this point.
No, it isn't silly at all.
Silly is having a whole physical dependency on an entire repo just to have a one line macro.
That's why C++11 libraries define their own instead of using StaticAssert.
But then there's another silly thing. You define your own macro, but this just moves StaticAssert from a primary dependency to a secondary dependency because Core brings it in.
We don't want silly things.
Again, then move the macro into Core or Config. Code duplication is not the answer. We have libraries to reuse code. If we're not using our own libraries, what does that tell us? 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. 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.
On Wed, Oct 22, 2025 at 6:06 PM Andrey Semashev via Boost < 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.
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/
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 Thanks
Vinnie Falco wrote:
On Wed, Oct 22, 2025 at 6:06 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
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
The traditional approach is to use "" as the string. :-) There's a reason C++17 added the one argument static_assert. As it turns out, (a) people really don't want to think about what strings to put and (b) the expression is the more informative part anyway.
On Thu, Oct 23, 2025 at 3:28 AM Peter Dimov via Boost <boost@lists.boost.org> wrote:
(b) the expression is the more informative part anyway.
This may be offtopic a bit, but I would say the state of things is a bit
more complex. In my view issue was that you could not produce a nice message for user until recently. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2741r3.pdf
Ivan Matek wrote:
On Thu, Oct 23, 2025 at 3:28 AM Peter Dimov via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org> > wrote:
(b) the expression is the more informative part anyway.
This may be offtopic a bit, but I would say the state of things is a bit more complex. In my view issue was that you could not produce a nice message for user until recently. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2741r3.pdf
Nobody is going to use this, just like they don't use the C++11 two argument static_assert. :-) (Here "nobody will use it" means "99.9% of the C++ developers won't" and not "literally zero occurrences of static_assert will use it", as there will exist a few libraries that will, e.g. the MS STL probably would.)
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.
Andrey Semashev wrote:
Again, then move the macro into Core or Config.
Moving the macro to Core is stupid. If a library does not already depend on Core, it won't want to depend on Core, which is a heavier dependency. 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. I didn't see any benefits from not making it public. Libraries that already depend on Core can take advantage of it. 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.
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.
Andrey Semashev wrote:
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?
Already answered in my first message.
What is the urgency that you want to add it before moving BOOST_STATIC_ASSERT into Config?
BOOST_STATIC_ASSERT hasn't moved into Config for many years now.
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?
They can keep doing it for a few more decades, of course.
On 23 Oct 2025 04:40, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
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?
Already answered in my first message.
You didn't. Not the "right now" part.
What is the urgency that you want to add it before moving BOOST_STATIC_ASSERT into Config?
BOOST_STATIC_ASSERT hasn't moved into Config for many years now.
Then, apparently, depending on StaticAssert wasn't such a big deal. If it is now then let's move it. After the release.
Andrey Semashev wrote:
On 23 Oct 2025 04:40, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
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?
Already answered in my first message.
You didn't. Not the "right now" part.
"Right now" doesn't affect my answer. The timing is arbitrary, as would be any delay.
On 23 Oct 2025 04:55, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
On 23 Oct 2025 04:40, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
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?
Already answered in my first message.
You didn't. Not the "right now" part.
"Right now" doesn't affect my answer. The timing is arbitrary, as would be any delay.
If timing is not essential then let's do it the right way and save everyone from the deprecation of BOOST_CORE_STATIC_ASSERT. Let's revert the addition of BOOST_CORE_STATIC_ASSERT and then, after the release, merge BOOST_STATIC_ASSERT into Config.
Andrey Semashev wrote:
If timing is not essential then let's do it the right way and save everyone from the deprecation of BOOST_CORE_STATIC_ASSERT. Let's revert the addition of BOOST_CORE_STATIC_ASSERT...
If that's the consensus, then sure, I'll delete static_assert.qbk and rename the macro to BOOST_CORE_DETAIL_STATIC_ASSERT. We already did that for core::string_view, why not do it again, the procedure has been a smashing success and of enormous benefit to everyone.
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?
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
El 24/10/2025 a las 9:32, Alexander Grund via Boost escribió:
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.
Well. I would say that ideally Boost.StaticAssert should just go once Boost.Config includes BOOST_STATIC_ASSERT and ports tests/doc to the Config repo. Users won't notice anything because Boost.Config will provide <boost/static_assert.hpp> when Boost.StaticAssert goes away. Or am I missing something? Best, Ion
Ion Gaztañaga wrote:
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.
Well. I would say that ideally Boost.StaticAssert should just go once Boost.Config includes BOOST_STATIC_ASSERT and ports tests/doc to the Config repo. Users won't notice anything because Boost.Config will provide <boost/static_assert.hpp> when Boost.StaticAssert goes away. Or am I missing something?
It should probably remain so that boost.org/libs/static_assert keeps working, but the header doesn't need to be there, it would move to Config.
On 24 Oct 2025 16:25, Peter Dimov via Boost wrote:
Ion Gaztañaga wrote:
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.
Well. I would say that ideally Boost.StaticAssert should just go once Boost.Config includes BOOST_STATIC_ASSERT and ports tests/doc to the Config repo. Users won't notice anything because Boost.Config will provide <boost/static_assert.hpp> when Boost.StaticAssert goes away. Or am I missing something?
It should probably remain so that boost.org/libs/static_assert keeps working, but the header doesn't need to be there, it would move to Config.
It should remain as long as other Boost libraries refer to static_assert submodule, but once they are updated it can be removed.
В письме от четверг, 23 октября 2025 г. 05:21:22 MSK пользователь Peter Dimov via Boost написал:
We already did that for core::string_view, why not do it again, the procedure has been a smashing success and of enormous benefit to everyone.
Can confirm. I am very enthusiastic about having this—https://www.boost.org/ doc/libs/latest/libs/json/doc/html/ref/string_view.html—in Json docs, rather then just linking to a page in Core's docs such as what I did here for Container: https://www.boost.org/doc/libs/latest/libs/json/doc/html/ref/ storage_ptr/operator_star.html. I was in fact so enthusiastic about it, that I have asked to make the type public (https://lists.boost.org/archives/list/ boost@lists.boost.org/thread/FZRC6VSGV6MW2NGOAK3HCHOFCIYUUNVY/ #BKM6JWZKDCMMTWOIYTW2TEZO7YRATPB3). Url's and Charconv's maintainers decided to not play along with the charade and reference boost::core::string_view directly with the obvious drawback that that type is not documented anywhere.
On 23 Oct 2025 05:21, Peter Dimov via Boost wrote:
We already did that for core::string_view, why not do it again, the procedure has been a smashing success and of enormous benefit to everyone.
My proposal here is to not have the alternative macro in Core but instead make StaticAssert satisfy more people. You will only have that problem if you keep the macro in Core. So your sarcasm is misplaced. As for string_view, either way it would have been bad. Specifically, having two string_views (three, if you count std::string_view) is bad since it causes all kinds of ambiguities. If anything, I would have preferred if core::string_view didn't exist or if it *replaced* string_view from Utility. But alas, that was not agreed upon and we have what we have. And for Boost users, I believe, it is better to have just one string_view type that they can use themselves and interface with Boost libraries. If people think I'm wrong, go ahead and do what you think is right.
On 23/10/2025 13:30, Andrey Semashev via Boost wrote:
On 23 Oct 2025 05:21, Peter Dimov via Boost wrote:
We already did that for core::string_view, why not do it again, the procedure has been a smashing success and of enormous benefit to everyone. My proposal here is to not have the alternative macro in Core but instead make StaticAssert satisfy more people. You will only have that problem if you keep the macro in Core. So your sarcasm is misplaced.
As for string_view, either way it would have been bad. Specifically, having two string_views (three, if you count std::string_view) is bad since it causes all kinds of ambiguities.
Violent agreement here, one key selling point of Boost is so that folks don't have to keep wheel-reinventing, it seems a shame if we're doing here. John.
El 23/10/2025 a las 18:34, John Maddock via Boost escribió:
On 23/10/2025 13:30, Andrey Semashev via Boost wrote:
On 23 Oct 2025 05:21, Peter Dimov via Boost wrote:
We already did that for core::string_view, why not do it again, the procedure has been a smashing success and of enormous benefit to everyone. My proposal here is to not have the alternative macro in Core but instead make StaticAssert satisfy more people. You will only have that problem if you keep the macro in Core. So your sarcasm is misplaced.
As for string_view, either way it would have been bad. Specifically, having two string_views (three, if you count std::string_view) is bad since it causes all kinds of ambiguities.
Violent agreement here, one key selling point of Boost is so that folks don't have to keep wheel-reinventing, it seems a shame if we're doing here.
John.
Right. Now I'll repeat my eternal proposal of moving also Boost.Assert to Core after we finish with Boost.StaticAssert ;-) Ion
On Thu, Oct 23, 2025 at 9:36 AM John Maddock via Boost < boost@lists.boost.org> wrote:
one key selling point of Boost is so that folks don't have to keep wheel-reinventing
Another key selling point of Boost is the federated development model. Authors are free to do what they think is in the best interests of their library and their users. There is no top-down command hierarchy (just look at what happened when a mandate to switch to cmake was issued). core::detail::string_view exists because the alternative (core::string_view) is less usable. The respective authors had a difference of opinion. For the record, I use core::detail::string_view because it is what works best for my users. So if giving users what works best is "wheel-reinventing," then prepare yourself for many more incoming wheels. Thanks
participants (9)
-
Alexander Grund -
Andrey Semashev -
Dmitry Arkhipov -
Ion Gaztañaga -
Ivan Matek -
John Maddock -
Peter Dimov -
Vinnie Falco -
Архипов Дмитрий