Re: Boost.Beast state of play

From: Darryl Green (darryl.green_at_[hidden])
Date: 2020-07-03 11:32:57

On Fri, 3 Jul 2020 at 20:25, Andrey Semashev via Boost
<boost_at_[hidden]> wrote:
>
> 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
<boost_at_[hidden]> wrote:
>
> 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.