On Fri, 3 Jul 2020 at 20:25, Andrey Semashev via Boost
On 2020-07-03 12:25, Paul A Bristow via Boost wrote:
All Boost releases risk causing someone trouble (and one way or another most do).
IMO Vinnie has made a good enough case for *this issue* on *this release*.
Vinnie's case was "because of WG21 politics". This is not a valid reason to compromise Boost quality, I totally agree with Ville on this. I find it somewhat disturbing that maintainers of a popular Boost library find that acceptable. Boost users experience should have a priority over WG21.
Richard, however, presented a different case, that is:
- Only a single test case is broken in a single configuration. - The test uses modern C++ features, which are expected to be rather unstable at this point. - There is a high chance that Chris will fix the problem before the release.
And Chris presented the features available as a consequence of these
changes, and the options for users.
My comments below are as a user of asio and Beast (and a lot of other
Boost libraries - not all ones that have become or are likely to
become part of std::).
On Fri, 3 Jul 2020 at 11:11, Christopher Kohlhoff via Boost
1) BOOST_ASIO_NO_DEPRECATED
The handler invocation and allocation hooks were superseded and deprecated back in Boost 1.66, with the introduction of the networking TS compatibility:
https://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/net_ts.html
The only deprecation-related change for Asio in Boost 1.74 is that these hooks are now covered by BOOST_ASIO_NO_DEPRECATED. This will help users find and replace their usage of the hooks in their applications.
Beast changed to respect the definition of BOOST_ASIO_NO_DEPRECATED in relation to these hooks.
Nice. I like this so I can do that (find usage of deprecated hooks).
2) BOOST_ASIO_NO_TS_EXECUTORS
With Boost 1.74, Asio adds an implementation of the proposed C++23 standard executors. This is in addition to the existing executors implementation which is defined in the networking TS.
Most applications will require no modification, or very little. If absolutely necessary, users can define BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT to enable full backward compatibility.
Nice to know I can do this if I need to.
A user may choose to define BOOST_ASIO_NO_TS_EXECUTORS so that they can disable networking TS executors entirely, and use only the proposed C++23 executors. Even when this is defined, unless interacting directly with executors at a low level, most code will require little or no change.
I don't want to do that - yet. But it's a nice-to-have for when/if there is a C++23 executor impl I want to use (for me, no rush, and certainly not in prod code).
Beast changed as follows:
* To support the proposed C++23 standard executors implementation as an additive feature.
* To respect the user's definition of BOOST_ASIO_NO_TS_EXECUTORS.
Good to know that whatever pain this migration may entail, Beast has it covered and I can experiment not just with my code that uses asio but also in code that uses Beast.
The common theme here is that these changes impact Beast more than they will impact end users, because Beast opts to support and pass through Asio's latest features without attenuation. This allows Beast users to employ these latest features in their applications.
I'm really happy to see this approach. It seems to be exactly what Boost should be doing. As a Boost user, I won't update to the new Boost release in existing production code without careful consideration of any impacts. On the other hand, I will, in new or evolving code, be keen to use new features and stop using deprecated ones - the fact that I can do both using this release is ideal. This is a great example of effectively resolving the conflict between Boost as a distribution of high quality code one can depend on (in some cases for many years) when that code is not part of the standard (or the standard library being used) and also providing a whole environment that can evolve and test the fitness of both the existing (through adaptation) and then newcomer (through filling a niche in this ecosystem). This effort should be applauded - including the level of testing of new unusual configurations being performed. If only every library/product was as thorough. I don't see this as an indication of dropping the quality of the release at all.