On Sat, May 2, 2020 at 9:15 AM Glen Fernandes via Boost wrote:

are you asking for a 1.73.1 Boost release?

What are the pros and cons of each option? Thanks

On Sat, May 2, 2020 at 9:34 AM Glen Fernandes wrote:

A new release is costly

Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested. Thanks

On 5/2/20 10:44 AM, Vinnie Falco via Boost wrote:

On Sat, May 2, 2020 at 9:34 AM Glen Fernandes wrote:

...

A new release is costly

Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested.

We'll have another release in 2-4 months. I very much doubt that there are many users who are currently using Beast with C++20. And I don't see a huge hardship if those users need to wait a couple of months. I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back. better to spend a little more time to tweak the testing/release process so that such a thing can't recurre. Robert Ramey

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

FYI - Boost practice is to prefer bottom posting. On 5/2/20 2:09 PM, Richard Hodges via Boost wrote:

Thank you all for your help and attention.

I have been spending the day investigating the root cause of compilation problems and extensively testing our fix.

In summary, I am inclined to de-escalate for now as I have discovered that neither

* clang-10 -std=c++20, nor * gcc-10 -std=c++20

will compile any asio program which involves a call to asio::co_spawn, which is fundamental requirement in a coroutine-enabled asio program.

What seems to be happening is that when concepts are enabled (which they are in the above compilers) asio is checking the result_of the supplied coroutine.

In clang-9 with -fcoroutines-ts, concepts are not enabled, so the check is not made.

I thinik I have been told previously by Lewis that it's not possible to take the result_of a coroutine. It's entirely possible that I have misunderstood as coroutine implementation is not yet my domain of expertise.

In summary, one of either (Asio && MSVC) || (clang && gcc) are in the wrong.

I am not qualified to say which at this stage.

I suspect there's a workaround in clang & gcc which will involve using macro definitions to convince asio that concepts are not available when compiled in c++20.

It's late for me now but I'll check this train of thought in the morning.

R

On Sat, 2 May 2020 at 22:11, Robert Ramey via Boost wrote:

...

On 5/2/20 10:44 AM, Vinnie Falco via Boost wrote:

...

On Sat, May 2, 2020 at 9:34 AM Glen Fernandes wrote:

...

A new release is costly

Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested.

We'll have another release in 2-4 months. I very much doubt that there are many users who are currently using Beast with C++20. And I don't see a huge hardship if those users need to wait a couple of months. I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back.

better to spend a little more time to tweak the testing/release process so that such a thing can't recurre.

Robert Ramey

...

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Sat, 2 May 2020 at 23:09, Richard Hodges wrote:

Thank you all for your help and attention.

I have been spending the day investigating the root cause of compilation problems and extensively testing our fix.

In summary, I am inclined to de-escalate for now as I have discovered that neither

* clang-10 -std=c++20, nor * gcc-10 -std=c++20

will compile any asio program which involves a call to asio::co_spawn, which is fundamental requirement in a coroutine-enabled asio program.

What seems to be happening is that when concepts are enabled (which they are in the above compilers) asio is checking the result_of the supplied coroutine.

In clang-9 with -fcoroutines-ts, concepts are not enabled, so the check is not made.

I thinik I have been told previously by Lewis that it's not possible to take the result_of a coroutine. It's entirely possible that I have misunderstood as coroutine implementation is not yet my domain of expertise.

In summary, one of either (Asio && MSVC) || (clang && gcc) are in the wrong.

I am not qualified to say which at this stage.

I suspect there's a workaround in clang & gcc which will involve using macro definitions to convince asio that concepts are not available when compiled in c++20.

Confirmed: adding -DBOOST_ASIO_DISABLE_CONCEPTS to the command line options of clang-10 allows compilation.

It's late for me now but I'll check this train of thought in the morning.

R

On Sat, 2 May 2020 at 22:11, Robert Ramey via Boost wrote:

...

On 5/2/20 10:44 AM, Vinnie Falco via Boost wrote:

...

On Sat, May 2, 2020 at 9:34 AM Glen Fernandes wrote:

...

A new release is costly

Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested.

We'll have another release in 2-4 months. I very much doubt that there are many users who are currently using Beast with C++20. And I don't see a huge hardship if those users need to wait a couple of months. I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back.

better to spend a little more time to tweak the testing/release process so that such a thing can't recurre.

Robert Ramey

...

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

On 5/2/20 10:10 PM, Robert Ramey via Boost wrote:

We'll have another release in 2-4 months.  I very much doubt that there are many users who are currently using Beast with C++20.  And I don't see a huge hardship if those users need to wait a couple of months.  I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back.

FWIW, Linux distros would pick up the patch themselves, as well as anyone that is affected, when needed. So as long as it's a known issue after release, it's not a problem just to have it listed as an errata or a known issue with a patch. No need for point release if almost everything else works as advertised. Best, Adam