You need modules urgently.
Sent from Mail for Windows
From: boost-request@lists.boost.org
Sent: Sunday, 8 May 2022 10:00 PM
To: boost@lists.boost.org
Subject: Boost Digest, Vol 6699, Issue 1
Send Boost mailing list submissions to
boost@lists.boost.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.boost.org/mailman/listinfo.cgi/boost
or, via email, send a message with subject or body 'help' to
boost-request@lists.boost.org
You can reach the person managing the list at
boost-owner@lists.boost.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Boost digest..."
The boost archives may be found at: http://lists.boost.org/Archives/boost/
Today's Topics:
1. Re: Any objections to making C++14 the current baseline for
Boost support and testing? (Seth)
2. Re: Any objections to making C++14 the current baseline for
Boost support and testing? (Christopher Kormanyos)
3. Re: Any objections to making C++14 the current baseline for
Boost support and testing? (Bo Persson)
----------------------------------------------------------------------
Message: 1
Date: Sat, 07 May 2022 15:30:08 +0200
From: Seth
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)
------------------------------
Message: 2
Date: Sun, 8 May 2022 09:31:19 +0000 (UTC)
From: Christopher Kormanyos
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
------------------------------
Message: 3
Date: Sun, 8 May 2022 12:37:00 +0200
From: Bo Persson
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
------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6699, Issue 1 **************************************