Any objections to making C++14 the current baseline for Boost support and testing?
Pursuant of discussion elsewhere: Does anyone have any concrete objections to Boost moving to a C++14 baseline? This would mean: * Library authors can drop and remove all support for pre-C++14 compilers after a suitable deprecation notice in place for say 3 releases. * The community maintenance team can likewise drop pre-C++14 support from community maintained / orphan libaries. * CI tests no longer need report pre-C++14 results. * From the next release onward, the boost super-project should clearly announce in our release notes, that C++11 and earlier support may no longer be available from the start of 2023. Thoughts? Thanks, John Maddock.
Pursuant of discussion elsewhere:
Does anyone have any concrete objections to Boost moving to a C++14 baseline? Yes. I do.(Caveat: But I'll be happy to be over-ruled.)
We recently established that C++/Boost are uniqueinsofar as they provide high-level abstractionson top of the C++ language. This C++ languagecreates optimized, compiled object that is nearenough to the machine to facilitate high-performance.
Along those lines, a lot of clients use Boost/C++with older compilers, not because they cherisholder compilers, but since constraints makethem end up stuck there. These are constraintssuch as legacy customer projects, old compilers,legacy licenses, old embedded compilers, and more.
Boost provides a service.
So I would turn around the question...
How low do we have to go tobe moderately modern while supportingas many clients as possible?
in my experience, people might get stuckaround GCC4.8/C++11 and GCC 5.4/C++11-14.For the first sticky point, I'd like to see C++11in this baseline. I can't imagine anyone really*needing* 14 features to express their LIB(better than with 11). Even though 14 has lotsof bug fixes, the only real key advanced featureis relaxed constexpr constraints anddigit separators.
So somehow, even if there is reticance to do so,I'd like that 11 support. But I wont struggle toohard for it.
Kindest regards for this thread, John and all,Chris
On Friday, May 6, 2022, 10:20:25 AM GMT+2, John Maddock via Boost
Even though 14 has lotsof bug fixes, the only real key advanced featureis relaxed constexpr constraints anddigit separators.
I'd say that polymorphic lambdas, lambda capture initializers, return type deduction, decltype(auto) are all more important and really felt. I can live without the library features (because they're easy to provide, except the UDLs)
Even though 14 has lotsof bug fixes, >> the only real key advanced featureis>> relaxed constexpr constraints >> and digit separators. I apologize for my perhaps unwisely chosen(or even wrong) wording.
I'd say that polymorphic lambdas, lambda> capture initializers, return type deduction,> decltype(auto) are all more important> and really felt. ... And I do respect this comment. But I'm not quite ready to give upon eleven just yet...
Let's argue the controversial C++11/14baseline issue from a purely service-oriented,product-management point of view.
Boost has a deep symbiosis with C++11and vice-versa. There are clients usingBoost with C++11.
To drop C++11 from a product/servicepoint of view should only be allowed ifa viable option is provided --- freelyand easily obtained --- for those clientsusing Boost with C++11.
So I would say, prove to the clients,prove to ourselves what this optionactually is. Which option will allowclients stuck on C++11 (maybe notby choice) to continue to use Boostwithout C++11 support?
One possibility comes to mind:Freeze at 1.80 if you need C++11,but I don't like this option.
Kind regards, Chris
On Saturday, May 7, 2022, 03:36:26 PM GMT+2, Seth via Boost
Even though 14 has lotsof bug fixes, the only real key advanced featureis relaxed constexpr constraints anddigit separators.
I'd say that polymorphic lambdas, lambda capture initializers, return type deduction, decltype(auto) are all more important and really felt. I can live without the library features (because they're easy to provide, except the UDLs) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2022-05-08 at 11:31, Christopher Kormanyos via Boost wrote:
Even though 14 has lotsof bug fixes, >> the only real key advanced featureis>> relaxed constexpr constraints >> and digit separators. I apologize for my perhaps unwisely chosen(or even wrong) wording.
I'd say that polymorphic lambdas, lambda> capture initializers, return type deduction,> decltype(auto) are all more important> and really felt. ... And I do respect this comment. But I'm not quite ready to give upon eleven just yet...
Let's argue the controversial C++11/14baseline issue from a purely service-oriented,product-management point of view. Boost has a deep symbiosis with C++11and vice-versa. There are clients usingBoost with C++11. To drop C++11 from a product/servicepoint of view should only be allowed ifa viable option is provided --- freelyand easily obtained --- for those clientsusing Boost with C++11. So I would say, prove to the clients,prove to ourselves what this optionactually is. Which option will allowclients stuck on C++11 (maybe notby choice) to continue to use Boostwithout C++11 support?
It can also be argued that we might do some clients a disservice instead of a service. If the new features are *that* useful for the library authors, would they not be equally useful for the clients' code? By supporting old compilers and standards we let them procrastinate for another couple of years. Is that good? Or should we encourage them to move on? Perhaps a gentle push is all they need? "New and improved" is often used in product-marketing. Why not here?
One possibility comes to mind:Freeze at 1.80 if you need C++11,but I don't like this option.
Kind regards, Chris
On Sat, May 7, 2022 at 6:36 AM Seth via Boost
I'd say that polymorphic lambdas, lambda capture initializers, return type deduction, decltype(auto) are all more important and really felt. I can live without the library features (because they're easy to provide, except the UDLs)
Those are nice and all, but none of them improve the public API or usability of a library. They help the implementer, author, or maintainer of a library but that's it. If a user wants to use these features listed above, they can still do so in their own code by using C++14 or later, even if the Boost library they are consuming is written for C++11 (or C++03). On the other hand features like `std::pmr::memory_resource` or `std::variant` _do_ affect the public API of a library. Thanks
Those are nice and all, but none of them improve the public API or usability of a library.
I second that. C++11 already does a good job at sending the message that we can upgrade again cautiously at some point.
On the other hand features like `std::pmr::memory_resource` or `std::variant` _do_ affect the public API of a library.
I would add std::string_view to this list. Also, pmr is not available on clang, so it's hard to count on it even if moving to C++17. https://godbolt.org/z/11Ez7f64q
On Fri, May 6, 2022 at 1:20 AM John Maddock via Boost-users
Does anyone have any concrete objections to Boost moving to a C++14 baseline?
Yes. If any of Boost.Beast's dependencies requires C++14, then Beast will require C++14. I am not quite ready to force half of Beast's existing userbase to upgrade to C++14 or later, or not use newer versions of Boost. Source: https://blog.jetbrains.com/wp-content/uploads/2021/07/cpp11_migration.png Thanks
participants (6)
-
Alan de Freitas -
Bo Persson -
Christopher Kormanyos -
John Maddock -
Seth -
Vinnie Falco