On 2/4/23 16:23, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

Also, I suggest we name the first Boost version that requires C++11 as Boost 2.0 and the C++03-compatible releases continue to be 1.x. The compiled binaries for 2.x should be named differently from 1.x, i.e. add a new tag in 2.x binaries.

This will be a much bigger change that will break _a lot_ more things than just C++03, so I'm not sure how enthusiastic I am about it.

...

This will make it easier for downstream consumers to ship 2.x and 1.x releases side by side, should it be needed. Point releases may not be convenient for downstream since, for example, Debian dev packages for Boost are named as libboost-math1.74-dev (no point version).

As long as the point releases are kept binary compatible, packagers can still replace 1.82.0 with 1.82.1 using their own versioning mechanism.

https://ubuntu.pkgs.org/22.04/ubuntu-universe-amd64/libboost-math1.74-dev_1....

But we don't support binary compatibility.

On Sat, Feb 4, 2023 at 8:52 AM Matt Borland via Boost wrote:

On Sat, Feb 4, 2023 at 04:46, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

On 2/4/23 15:08, Peter Dimov via Boost wrote:

...

Greetings,

I have a novel idea, let's drop C++03 support.

The reasons to do that have been explicated already a number of times, e.g. in

https://pdimov.github.io/articles/phasing_out_cxx03.html#_ongoing_costs_of_m...

...

but in brief:

* C++03 is 20 years old. * A number of intra-Boost dependencies can be eliminated by using the standard equivalent of Boost components. This will help Boost to become "more modular". * Variadic templates allow us to remove the uses of Preprocessor and MPL, which are the primary contributor to slow Boost compilation times. * Almost no new C++03 development occurs in Boost at this point, so C++03 users do not need to upgrade their Boost.

To that end, I propose the following:

Boost release 1.82.0 is announced as the last one with C++03 support. If critical problems are found in it post-release, we will issue 1.82.1, 1.82.2 and so on, as appropriate (as C++03 users will not be able to just upgrade to 1.83.)

For this to be possible, a separate set of branches need to be created for each library and the superproject. Possibly, CI scripts needs to be updated to test the new branches.

Also, I suggest we name the first Boost version that requires C++11 as Boost 2.0 and the C++03-compatible releases continue to be 1.x. The compiled binaries for 2.x should be named differently from 1.x, i.e. add a new tag in 2.x binaries. This will make it easier for downstream consumers to ship 2.x and 1.x releases side by side, should it be needed. Point releases may not be convenient for downstream since, for example, Debian dev packages for Boost are named as libboost-math1.74-dev (no point version).

...

Boost release 1.83.0 is announced to require C++11 at minimum. This means compilers that have all the C++11 standard headers, and support all the C++11 syntactic constructs and keywords without issuing errors. (E.g. VS2013 doesn't qualify because it doesn't support the `constexpr` or `noexcept` keywords.)

For gcc, the minimum version would be 4.8.1:

https://gcc.gnu.org/projects/cxx-status.html#cxx11

For clang, it's 3.3:

https://clang.llvm.org/cxx_status.html#cxx11

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

When we were converting Math to C++11 we found that the practical minimum for GCC was 5. If I remember correctly GCC 4.8 series support is broken. We don’t have any Clang earlier than 5 in the CI system either.

I'm guessing that you're referring to a specific CI system? The regression test do run against Clang 3.x: https://www.boost.org/development/tests/develop/developer/summary.html Specifically, the oldest compilers we're currently testing against are: gcc-4.6 clang-3.3 msvc-10.0 I'd personally support the community phasing out support of the older ones and make it: gcc-4.8 (Default in RHEL 7 and Ubuntu 18.04 LTS) clang-5 msvc-14.0 Tom

On 8/02/2023 01:06, Kostas Savvidis wrote:

I would add to the reasons the complete absense of any messages of protest on this list from projects that use boost with a 03-only compiler. That is, assuming, A) such projects exist and, B) they do upgrade to new boost versions instead of being stuck on some version which came out at a time when their project originated.

FWIW, as I said the last five times this topic came up, while I do indeed have some projects stuck on C++03 (and even older!) compilers, they're also permanently pegged to older Boost versions, and I don't forsee any reason to upgrade them in the future. I would imagine most others in a similar situation have similar views, though I might be wrong. Anyone required to use an old compiler is probably targeting an entire old ecosystem, that would naturally have old versions of all dependencies, including Boost. The rest probably could upgrade compiler flags if given a sufficient nudge. So I fully support existing libraries dropping C++03, especially if that might make them more likely to use C++11 or higher features where currently they might be avoiding them. All my "current" projects target C++17 at present. I'm less inclined towards dropping libraries entirely (though not strongly opposed -- if no willing maintainer comes forward after a specific library is put into the crosshairs, perhaps it deserves to die) or "Boost 2.0", but then that wasn't Peter's proposal anyway.

On 04.02.23 14:34, Andrey Semashev via Boost wrote:

Is the goal to drop C++03 or unmaintained Boost libraries? Those are two different goals.

Personally, I don't think dropping any Boost libraries, even unmaintained ones, benefits our users. Especially not, if it is impossible to use Boost 2.x and 1.x in the same code base. And I suspect that we don't want to mess with changing namespaces and macro names, which means 1.x and 2.x are mutually exclusive in the same code base.

I think if we're going to break backwards compatibility anyway, we might as well go all out and get rid of some of the cruft that has accumulated in Boost that is no longer relevant in a C++11+ world. I am thinking in particular of Boost libraries that exist only to emulate C++11 features in C++03, like Boost.Foreach. I generally favor backwards compatibility, but I also favor a single clean cut over a long drawn-out process of libraries slowly breaking due to no longer being maintained. -- Rainer Deyke (rainerd@eldwood.com)

On 4. Feb 2023, at 14:34, Andrey Semashev via Boost wrote:

Personally, I don't think dropping any Boost libraries, even unmaintained ones, benefits our users. Especially not, if it is impossible to use Boost 2.x and 1.x in the same code base. And I suspect that we don't want to mess with changing namespaces and macro names, which means 1.x and 2.x are mutually exclusive in the same code base.

bcp is the tool that we ship to have more than one Boost version in a project at the same time. It does the namespace renaming. Wouldn't this also work here to have both at the same?

sob., 4 lut 2023 o 15:00 Vinnie Falco via Boost napisał(a):

...

- When we go to version 2.0, Boost libraries would have to "opt in" to being part of the Boost collection. All this means is that those

On Sat, Feb 4, 2023 at 5:27 AM Glen Fernandes via Boost wrote: libraries

...

who do not have active maintainers would not opt in, and would not ship in Boost 2.

"Nothing unless opted in" appears too harsh. But maybe libraries that have a v2 could be left behind.

As long as Boost.Asio and Boost.Coroutine opt-in, I'm OK with this.

Do you mean specifically Boost.Coroutine (v1). We have Boost.Coroutine2 which appears to replace its v1 counterpart, and requires C++11. Or is there more to the story? Regards, &rzej;

Thanks

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

非常期待这一天早点到来！！！☺☺☺

boost::spawn() from boost.asio depends on boost.coroutine. I've had suggested boost.spawn as a replacement for boost::spawn that depends only on boost.context. 04.02.2023 16:41:08 Klemens Morgenstern via Boost :

Yes, with the next release beast will only rely on boost.context (including tests). Asio has also marked the functions using boost.coroutine as deprecated, so that it won't need boost.coroutine either..

If we do a boost 2.0 should we also try to unify things, i.e. make variant2 the boost.variant in 2.0 etc.?

On Sat, Feb 4, 2023 at 11:08 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

On Sat, Feb 4, 2023 at 7:06 AM Andrzej Krzemienski wrote:

...

Do you mean specifically Boost.Coroutine (v1). We have Boost.Coroutine2 which appears to replace its v1 counterpart, and requires C++11. Or is there more to the story?

I am so sorry.. I meant Boost.Context (Klemens is this right?)

Thanks

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

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

But what happens with asio's boost::spawn()? 04.02.2023 16:08:40 Vinnie Falco via Boost :

On Sat, Feb 4, 2023 at 7:06 AM Andrzej Krzemienski wrote:

...

Do you mean specifically Boost.Coroutine (v1). We have Boost.Coroutine2 which appears to replace its v1 counterpart, and requires C++11. Or is there more to the story?

I am so sorry.. I meant Boost.Context (Klemens is this right?)

Thanks

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

Robert Ramey wrote:

On 2/4/23 10:50 AM, Peter Dimov via Boost wrote:

...

As long as a C++11 compiler is used, code that compiles and works with 1.82 should continue to compile and work with 1.83, without changes.

The serialization library consists of code from 2002 which is tested at each release to be sure it works with all known C++ compilers. A few tests are elided on one or another platforms because they depend on standard libraries which have been added/dropped over the years.

May I presume that this doesn't affect me and I can ignore it?

Yes, I think you can. Nothing will be required on your end.

On 2/4/23 11:05 PM, Andrzej Krzemienski via Boost wrote:

niedz., 5 lut 2023 o 01:29 Peter Dimov via Boost napisał(a):

...

...

On 2/4/23 10:50 AM, Peter Dimov via Boost wrote:

...

As long as a C++11 compiler is used, code that compiles and works with 1.82 should continue to compile and work with 1.83, without changes.

The serialization library consists of code from 2002 which is tested at each release to be sure it works with all known C++ compilers. A few tests are elided on one or another platforms because they depend on standard

Robert Ramey wrote: libraries

...

which have been added/dropped over the years.

May I presume that this doesn't affect me and I can ignore it?

Yes, I think you can. Nothing will be required on your end.

However, if I understand the idea correctly, you might not be able to offer a c++03 support anymore. If Boost.Serialization depends on Boost.Optional and Boost.Optional depends on Boost.TypeTraits,

I'm pretty sure it doesn't

and Boost.TypeTraits decide tos remove the code for C++03 compatibility, then Boost.Serialization loses C++03 compatibility also.

Right. I think the wording is confusing here. The proposal is not to drop 03 support - whatever that means. The proposal is to deprecate and remove a few older boost libraries which some library and user code might depend. So - understood this way I get it. I still don't see what benefit obtains though. Robert Ramey

Regards, &rzej;

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

Robert Ramey wrote:

Right.

I think the wording is confusing here. The proposal is not to drop 03 support -

That is exactly the proposal.

whatever that means. The proposal is to deprecate and remove a few older boost libraries which some library and user code might depend.

No, the proposal is not to deprecate and remove Boost libraries.

On Sun, 5 Feb 2023 at 19:04, Peter Dimov via Boost wrote:

Robert Ramey wrote:

...

whatever that means. The proposal is to deprecate and remove a few older boost libraries which some library and user code might depend.

No, the proposal is not to deprecate and remove Boost libraries.

Aha! It is to "to remove the uses (...)" [1] [1] https://lists.boost.org/Archives/boost/2023/02/253986.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

So - understood this way I get it. I still don't see what benefit obtains though.

I maintain Unordered, which is a C++03 library. Dropping C++03 support dramatically simplifies life on my end as it's becoming increasingly more difficult to download older and older compilers and toolchains. While many CI solutions may offer these things, finding them yourself to locally replicate CI failures isn't always easy or fun. Shifting away from C++03 and setting C++11 as a minimum, where C++11 is defined as Peter did for us in his opening post, would go a long way towards making life easier for future maintainers down the line. It eases the burden on our CI and our authors and maintainers and to me, that's the benefit we obtain. - Christian

On 2/5/23 3:39 PM, Robert Ramey via Boost wrote:

On 2/5/23 1:25 PM, Christian Mazakas via Boost wrote:

You could obtain this benefit tomorrow.  Just set the policy for the library you maintain.

I maintain the Boost Serialization Library. It's consistent with (supports?) C++03. For the last 20 years, all I've done is bug fixes and updates to be build system scripts. No one has complained - and of course why would they? I also maintain the Boost Safe Numerics Library. It requires C++14 or higher to use. (It's header only so there is no build). Does the means it "supports" C++14? Neither of these two libraries violate any boost policy that I'm aware of. Robert Ramey. P.S. I can't help that the word "supports" is ill-chosen here. I honestly don't understand what it means in this context.

On 2/5/23 4:05 PM, Glen Fernandes via Boost wrote:

On Sun, Feb 5, 2023 at 6:47 PM Robert Ramey wrote:

...

I maintain the Boost Serialization Library. It's consistent with (supports?) C++03. For the last 20 years, all I've done is bug fixes and updates to be build system scripts. No one has complained - and of course why would they?

P.S. I can't help that the word "supports" is ill-chosen here. I honestly don't understand what it means in this context.

Robert, the only way the proposed announcement would affect you is the following:

Let's say you decide you want Boost.Serialization to continue to work in C++03 compilers. Imagine the announcement is made that "Boost 1.82 is the last release where the release managers will care about tests failing in C++03 standards mode". Now Boost.Serialization depends on some other Boost libraries, for example, it uses boost::addressof() from Boost.Core. In Boost 1.83 let's say we make a change to boost::addressof such that it no longer compiles in C++03 mode. Now Boost.Serialization in 1.83 will also not compile in C++03 mode.

So in that scenario: If you wanted Boost.Serialization to continue to be usable in C++03 code, you would have to stop depending on boost::addressof and have your own boost::serialization::addressof implementation, etc.

Glen

That's what I've always thought. In the case of the serialization library, I expect the only non-trivial case would be deprecation of MPL. Even that wouldn't be a big issue. I've already found MP11 to be a nice improvement. I don't think it would be much work. But then it still be more work than nothing which is what is is now. I'm still not getting how anyone's life is going to be made simpler with all this. The affected code is "old-fashioned". But it's an implementation detail and it's well tested. If you stop testing C++03, you'll find that libraries are going to automatically and inevitably migrate to the level of the lowest tested library. (Ramey's second law) FYI - Ramey's first law, if you leave the documentation until the end, you'll end up refactoring the API.

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

Andrzej Krzemienski wrote:

Let me do a small exercise to check if I understood what is being proposed. The following sentences were *not* said by Peter. I am making these claims, based on my understanding, and I would ask you, Peter, to say if they are correct in the context of the proposal.

Suppose that 1.83 is the first release where the proposal is implemented.

1. This means that the author of library Boost.X can declare "support for C++03 is deprecated, and it will be removed in 1.85". In 1.85 the author is allowed to make changes such that when library Boost.X is compiled with - std=C++03 a hard error is issued. This means that if library Boost.Y uses (or depends on) Boost.X and library Boost.Z depends on Boost.Y and The author of Boost.Z claims that they support C++03, this support suddenly breaks in library Boost.Z (because library Boost.X now issues an error on -std=C++03).

If the proposal is adopted, the author of Boost.X can remove the support for C++03 in 1.83, without going through the deprecation procedure.

2. The implication of the above is that only the "leaf libraries" (those that no other Boost library depends on) can safely remove the C++03 support.

No, every library will be free to remove C++03 support starting with 1.83 (under the assumption that we declare 1.82 as the last Boost release supporting C++03.)

I am 100% in favor of dropping 03 support, for the reasons Peter listed. No need to change the names of things, or bump the major release number, IMO. Zach On Sat, Feb 4, 2023 at 12:50 PM Peter Dimov via Boost wrote:

...

To that end, I propose the following:

Boost release 1.82.0 is announced as the last one with C++03 support. If critical problems are found in it post-release, we will issue 1.82.1, 1.82.2 and so on, as appropriate (as C++03 users will not be able to just upgrade to 1.83.)

Boost release 1.83.0 is announced to require C++11 at minimum. This means compilers that have all the C++11 standard headers, and support all the C++11 syntactic constructs and keywords without issuing errors. (E.g. VS2013 doesn't qualify because it doesn't support the `constexpr` or `noexcept` keywords.)

Since people have come up with various creative ways to break all existing code using Boost, and I've been asked off-list "but don't you want to break things", I want to clarify that those are completely outside the scope of my proposal. It is exactly as outlined above, no more and no less. I do not propose "Boost 2.0", replacing the includes with boost2/foo.hpp, replacing the library names with libboost2_foo, bumping the version to 2.0, dropping libraries from Boost, and anything like.

As long as a C++11 compiler is used, code that compiles and works with 1.82 should continue to compile and work with 1.83, without changes.

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

Boris Kolpackov wrote:

...

Boost release 1.83.0 is announced to require C++11 at minimum. This means compilers that have all the C++11 standard headers, and support all the C++11 syntactic constructs and keywords without issuing errors. (E.g. VS2013 doesn't qualify because it doesn't support the `constexpr` or `noexcept` keywords.)

IME, this is an unreliable criterion. For example, based on this MSVC 14.3 (VS2015) would be a fair game but in practice its constexpr support is so buggy/incomplete that it's pretty much unusable.

On the contrary, it's a highly reliable criterion. It allows you to write "constexpr" instead of "BOOST_CONSTEXPR" without the compiler issuing an immediate error. How useful would that function be in a constant expression context is another story. (MSVC 14.3 is VS2022, not VS2015.)

Andrey Semashev wrote:

On 2/6/23 16:40, Peter Dimov via Boost wrote:

...

Boris Kolpackov wrote:

...

IME, this is an unreliable criterion. For example, based on this MSVC 14.3 (VS2015) would be a fair game but in practice its constexpr support is so buggy/incomplete that it's pretty much unusable.

On the contrary, it's a highly reliable criterion. It allows you to write "constexpr" instead of "BOOST_CONSTEXPR" without the compiler issuing an immediate error.

I think, the point is that while you can write "constexpr", the compiler will likely fail to compile that code in most/all real world contexts. The question is what do we, Boost maintainers, do when users come complaining. I think, listing the minimum compiler versions we support would be useful.

If a compiler issues an error on the mere appearance of the keyword "constexpr", or "noexcept", or "=default", it's not a C++11 compiler. This is not rocket science. Yes, a compiler may support the constexpr keyword, but have problems with complex uses. This is not a good criterion for banning it Boost-wide, because "complex uses" vary. One library may not be able to support it, another might. If you insist on not considering msvc-14.0 a C++11 compiler for your libraries, that's your right (and problem.) It has nothing to do with whether it's considered a supported C++11 compiler for the purposes of the announcement.

Boris Kolpackov wrote:

Peter Dimov via Boost writes:

...

Yes, a compiler may support the constexpr keyword, but have problems with complex uses. This is not a good criterion for banning it Boost-wide, because "complex uses" vary. One library may not be able to support it, another might.

If you insist on not considering msvc-14.0 a C++11 compiler for your libraries, that's your right (and problem.) It has nothing to do with whether it's considered a supported C++11 compiler for the purposes of the announcement.

I don't see how this is helpful to the users of Boost, especially considering the heavy dependencies between individual libraries. As a user I want to know if the set of libraries that I would like to use (plus their transitive dependencies) are compatible with my compiler/version.

It should be clear how not declaring msvc-14.0 a non-C++11 compiler and therefore unsupported by Boost 1.83.0+ is helpful for the users of msvc-14.0.

Maybe requiring support for all the language features or the standard library is not strictly necessary.

I would argue that it is necessary to strictly require full compliance with C++11. Invariably the libraries are going to have interdependencies, and strict compliance would give us a known lowest common denominator. Let’s say Boost.X uses GCC 4.8 and depends on Boost.Y which switches from Boost.TypeTraits to since it no longer has to support C++03. Now Boost.X either has to increase it’s minimum compiler version to GCC 5, or the maintainer of Boost.Y is hamstrung trying to support Boost.X. To avoid this situation entirely we enforce strict C++11 compliance (e.g. GCC 5, Clang 5, MSVC 14.0). We could move something similar to this file (https://github.com/boostorg/math/blob/develop/include/boost/math/tools/cxx03...) out of math into config to throw hard errors on any non-compliant compiler. Matt

That's not entirely true. is functional under GCC 4.8, it's only missing

a handful of traits (is_trivially_*) and that's not hard to work around.

https://github.com/boostorg/variant2/blob/95a8c5ffec407533893fa39900bc7799c2...

Everything can be worked around by either a) trading one boost dependency for another (TypeTraits -> MP11) or b) rolling my own solution every time. I expect that we will stay at C++11 for years to come so drawing the line at fully compliant C++11 would be a clean cut. Matt

Ion Gaztañaga wrote:

MSVC 14.0 is not fully compliant, full conformance starts with VS2017 I think:

https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance- improvements-2017?view=msvc-170

No version of MSVC is fully compliant (and this can't be fixed without breaking ABI.) Neither is GCC for that matter. Compilers will always have bugs. You'll note that I don't have "fully compliant" anywhere in my criterion. This is not due to random chance.

On 08/02/2023 17:35, Peter Dimov via Boost wrote:

Ion Gaztañaga wrote:

...

We should set minimum versions of compilers that we should support and make sure we can test on those.

That's exactly what I did, but I expressed it in the form of an objective criterion instead of a version table for every possible compiler in existence.

Ok, understood. But that my point was that it is not related to when C++03 was defined. The important part for users is how old is the compiler they are using that supports the minimum standard. If full C++11 support was added to GCC just two years ago, we wouldn't set C++11 as minimum. "Expression SFINAE" was supported from Visual Studio 2017 (15.7) which I think was released in May 2018. So in theory Visual 2015 does not support C++11, that's why I was asking for minimal compilers. I think users will understand this easier than a compliance that maybe it's not easy to check in every aspect (language or library). Best, Ion

On 15. Feb 2023, at 21:15, David Sankel via Boost wrote:

On Sat, Feb 4, 2023 at 7:08 AM Peter Dimov via Boost wrote:

...

I have a novel idea, let's drop C++03 support.

I fully support this idea. There is clearly a tradeoff here, but I think reduction of support surface for our release infrastructure outweighs users stuck on legacy compilers.

I am against making a major version bump for it. If we were adding module support, that would be one thing, but dropping C++03 support in 2023 isn't exactly a thing I'd be crazy about advertising given our current branding challenges.

Full agreement with David on these two points.

actively harmful

Well it isn't for those users stuck on c++11. There are users for which the new facilities are quite beneficial.

rush to deliver spaceship broke some code

So what? Progress can't be made without *some* mistakes -- as you should know, there are a lot of complicated cases. The fixes for that breakage weren't difficult.

specific to WG21, it is a problem for any large organization. As Samo Burja explains in this blog post, functional institutions are the exception not the norm:

All this applies to Boost just as well as WG21.

Boost should not follow. Instead, we should lead.

As a member of Boost since the early 2000's I couldn't agree more. I don't think we are doing that currently, sorry. And continuing support for ancient revisions of the standard isn't a way to lead to the future. Vinnie -- I don't want to get into a big debate about this, it's not worth our time. But, yeah -- I disagree. On Fri, Feb 17, 2023 at 8:47 AM Vinnie Falco wrote:

On Fri, Feb 17, 2023 at 7:38 AM Jeff Garland via Boost wrote:

...

I'd dare to suggest we go one step further while we're here. We should join the 3 year cycle and drop support for c++11 in 2026, c++14 in 2029, etc.

Hmm, no I don't think that's a good idea. Dropping C++11 provides very little benefit compared to dropping C++03. And breaking existing Boost programs every three years doesn't sound particularly exciting.

...

...it matches what the standard is doing so it's already part of the bigger culture of evolution.

I don't agree that the Committee's three-year release cycle is beneficial. In fact I think it is actively harmful as things get rushed and it attracts thrill-seekers pursuing instant gratification. C++20 for example in its rush to "deliver spaceship" broke some existing programs.

In fact I would even say that WG21 is not effectively delivering on the needs of the greater C++ community. Not for lack of effort, but because the bureaucratic structure invites politics and creates perverse incentives. C++11 was a huge success thanks to Boost, and represents an outlier in terms of the quality of the Committee's output. What we are seeing today is a reduction of output, and a reversion to the mean.

This is not a problem specific to WG21, it is a problem for any large organization. As Samo Burja explains in this blog post, functional institutions are the exception not the norm:

https://samoburja.com/functional-institutions-are-the-exception/

Boost should not follow. Instead, we should lead.

Thanks

On Fri, Feb 17, 2023 at 5:50 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

* preparing "Powered By Boost" - a server that runs on Boost technology - deployed publicly - pages demonstrating Beast, MySQL, Redis - using Describe, Mustache (even though it is not in Boost yet) - open source - example code for doing things people want to do

Sounds great Vinnie. And I thank you for it. But... I also found the [Contemporary C++ in Action - Daniela Engert - CppCon 2022][1] vision compelling. And it sure wasn't created based on C++11 facilities. The combination of modules, concepts, coroutines, asio, etc... was impressive. I certainly can't use C++23 at work right now, I'm limited to C++17 for now, which is already newer than many. Asio w/o coroutines is just painful IMHO, for example. Compile times are painful, and modules seem to genuinely help, when used correctly. So there's lots of value in using the new moderner modern C++ facilities too, beyond C++11. I'm just a bystander. I don't know how Boost should function. Just saying. --DD [1]: https://www.youtube.com/watch?v=yUIFdL3D0Vk

Right. I'm going to skip over most of it because we'll never agree... On Fri, Feb 17, 2023 at 9:49 AM Vinnie Falco wrote:

On Fri, Feb 17, 2023 at 8:17 AM Jeff Garland wrote:

...

Well it isn't for those users stuck on c++11. There are users for which the new facilities are quite beneficial.

There is no question that new C++ features can be beneficial. But the nature of the bureaucracy is that it too steeply discounts the value of doing nothing.

C++23 will blow your mind then -- no significant language features were added.

Every new feature comes with an opportunity cost and the nature of the committee is that the authors of successful papers reap the benefits, while everyone else pays the costs.

There is no significant benefit to reap and there's no cost to users that ignore the feature.

Regardless of how "difficult" the fixes are, a key objective of new C++ standards is to not break existing programs.

That's your view and it's one objective, not the be all end-all for many of us. I could care less about c++17 compatibility, personally. But I understand why some care. Some have walked away from the committee because they think we need to break more to improve performance, etc.

...

...

...it is a problem for any large organization... All this applies to Boost just as well as WG21.

Well, no it doesn't. Boost is not a large organization, it has no bureaucracy, it has no voting, and it has no papers. It is actually a federation of independent libraries where each library is governed by a dictator whose interests are aligned with the users of the library. This setup ("social technology") is pretty darn effective. Collective progress is achieved by people willing to do things; the person proposing a solution is also the one incurring its cost of implementation. Thus economic incentives are aligned.

I'm well aware of how Boost works. There are good things and bad with it. Deprecating c++ 98 is an example of how the collective doesn't function -- it should have been done years ago in the opinion of many of us.

...

...

Boost should not follow. Instead, we should lead. As a member of Boost since the early 2000's I couldn't agree more. I don't think we are doing that currently, sorry.

Yes I think you are right about this.

Good, that's a start because I'm actually pretty sure we agree on more than we disagree.

When a successful organization loses its founders without solving the "succession problem"

...

Boost's founders stepped back (for the known reasons) the innovation slowed, and WG21 was seen as the preferred vehicle for achieving progress.

I'll take that as a personal jab :) Sure, I've stepped back from many kinds of participation here as have others. Largely to promote the Boost mission at WG21. However, Dimov, Maddock, there's still plenty of 'old guard' here.

...

And continuing support for ancient revisions of the standard isn't a way to lead to the future.

"continuing support for ancient revisions" is a strawman. There is an enormous quantitative difference in the cost of supporting C++03 versus the cost of supporting C++11. To be specific, we gain a lot from dropping C++03. We gain very little from dropping C++11: all we get is removing a few configurations from Continuous Integration. Not worth it.

Call it what you want, it's backward looking not forward looking. For me the missing part of the analysis is how many developers care about c++11 *only* at this point. gcc 11 which is a couple years old defaults to c++17. Survey's indicate that most developers are already on 14 or above. In 3 years I suspect it will be a tiny tiny fraction of the community.

...

I don't want to get into a big debate about this, it's not worth our time.

It is definitely worth my time, because the focus of 100% of my professional work output is to improve Boost. It is to lead by example, and refresh the foundations of Boost by performing the roles of the missing founders.

And let me say thanks at this point. I'd like to see Boost regain where it was, but I doubt it will ever happen despite all your efforts.

Instead of pointlessly breaking existing users every 3 years I am doing this:

* preparing a transition from boostbook to Asciidoc (boostbook is at end-of-life) * creating new Asciidoc style sheets to make our docs look good * helping build hdoc to replace our use of Doxygen (https://hdoc.io/)

hdoc requires a commercial license for commercial users many enterprises will no longer be able to build without paying. In my 2 minute review it also doesn't support /** style doc comments which seems like a regression. I'm all for modern docs, but less clear to me this is the path.

* preparing a new website to replace the existing Boost website * preparing "Powered By Boost" - a server that runs on Boost technology - deployed publicly - pages demonstrating Beast, MySQL, Redis - using Describe, Mustache (even though it is not in Boost yet) - open source - example code for doing things people want to do * promoting Boost on Twitter * continuing to deliver value for users with Boost libraries like JSON, URL - and the upcoming Buffers, Http.Proto, and Http.Io * sponsoring talks for CppCon and videos for the upcoming "Boost Recipes" youtube channel

All great stuff. Also some of this is irrelevant to c++11 users since many of those libraries require higher versions for good reason: Aedis (c++17) and Describe (C++14) for example. I retract my suggestion. Instead let's litigate deprecation on an ongoing basis instead.

On Fri, Feb 17, 2023 at 10:11 AM Jeff Garland wrote:

...many of those libraries require higher versions for good reason: Aedis (c++17) and Describe (C++14) for example.

Of course, hitting "Send" is the best way to discover that you had more to say. Often it is the case that newer standards don't really help the utility of my libraries. Sure, they help me as an implementor ("if constexpr" versus overloads for example) but the user is not affected and I can still achieve the same results but with more work and care. This is especially true for pure library features. It is relatively straightforward to backport the feature into Boost, as we are doing currently with charconv for instance. Sometimes though, a newer standard offers a compelling thing that cannot be substituted. co_await is one example. The language support enabling Boost.Describe is another example. Describe-enabled algorithms which work on the user's described types are pretty damn convenient. Our Powered By Boost technology server will require C++14 for this reason. Thus it is the case that over time, the advantages of switching to a newer standard increase while the costs of abandoning an older standard decreases.

...let's litigate deprecation on an ongoing basis instead.

Therefore, consensus to deprecate C++11 will naturally converge to agreement as the case for C++14 strengthens with each new library or program that uses its non-substitutable advantages. Thanks

On 2/17/23 19:17, Jeff Garland via Boost wrote:

...

rush to deliver spaceship broke some code

So what? Progress can't be made without *some* mistakes -- as you should know, there are a lot of complicated cases. The fixes for that breakage weren't difficult.

I wouldn't say so. We still haven't fixed Boost.Operators (not for the lack of trying), which still remains officially broken in C++20. https://github.com/boostorg/utility/issues/65 In fact, this very issue is the reason I'm hesitant upgrading my projects to C++20 and beyond.

On Fri, Feb 17, 2023 at 11:01 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:

...

On 2/17/23 19:17, Jeff Garland via Boost wrote:

...

...

rush to deliver spaceship broke some code

So what? Progress can't be made without *some* mistakes -- as you should know, there are a lot of complicated cases. The fixes for that breakage weren't difficult.

I wouldn't say so. We still haven't fixed Boost.Operators (not for the lack of trying), which still remains officially broken in C++20.

https://github.com/boostorg/utility/issues/65

In fact, this very issue is the reason I'm hesitant upgrading my

Andrey Semashev wrote: projects to

...

C++20 and beyond.

Seconded.

https://github.com/boostorg/function/issues/45

C++23 makes it somewhat better, but doesn't fix everything.

hmm well it either fixes it or it doesn't -- not sure, but this was applied as a DR to C++20 so we shouldn't have to wait for 23. https://github.com/cplusplus/papers/issues/1127

On 18/02/2023 06:41, Andrey Semashev wrote:

I wouldn't say so. We still haven't fixed Boost.Operators (not for the lack of trying), which still remains officially broken in C++20.

https://github.com/boostorg/utility/issues/65

AFAIK, the whole point of the spaceship changes was essentially to deliberately deprecate Boost.Operators; it should be no longer necessary to use any of it, because the compiler now does almost all of it for you. (Also, can someone explain why x == y <==> y == x is controversial? I have a hard time picturing a use case where you deliberately intend these to be non-commutative, outside of pathological library-fights.)

On 20/02/2023 12:00, Andrey Semashev wrote:

Regardless of the intention, this isn't a license to break existing code. There are reasons to keep using Boost.Operators in C++20 and beyond - one of them being compatibility with prior C++ versions.

Sure, but in theory Boost.Operators classes could just switch to a simplified implementation when C++20 is in use. Perhaps there are some cases that become tricky to map from one to the other, but less_than_comparable naturally maps to spaceship and equality_comparable happens for free, and most of the others shouldn't be affected, I would have thought?

Sometimes it seems the Committee just assumes the world will momentarily upgrade to the latest C++ standard and all legacy code cease to exist.

I don't think this is true; it's a long-standing joke that all of the default behaviours of C++ are wrong, in order to maintain backwards compatibility of legacy code. (See also: explicit, [[nodiscard]].) As someone who maintains a 40+-year-old codebase myself, I'm quite thankful that code in the dark recesses still mostly works without having to disturb the spiders.

On Sunday, February 19, 2023 5:08:45 P.M. CST Peter Dimov via Boost wrote:

Gavin Lambert wrote:

...

(Also, can someone explain why x == y <==> y == x is controversial?

...

I have a hard time picturing a use case where you deliberately intend

Thank you for asking this question, Gavin! It was the first thing I wondered when I read the original post. these

...

to be non- commutative, outside of pathological library-fights.)

Why is this "pathological"?

It breaks the idea that "==" is an equivalence relation, which seems to me to unnecessarily complicate things for the user.

If you allow heterogeneous comparisons, who decides the meaning of x == y, the author of x or the author of y?

As a user, I would hope/expect: 1. that I don't have to know or care that "x" and "y" are from different authors 2. the two authors would agree on equivalence -Steve

On 20/02/2023 17:09, Peter Dimov wrote:

...

It breaks the idea that "==" is an equivalence relation, which seems to me to unnecessarily complicate things for the user.

Heterogeneous comparisons aren't equivalence relations. Values of different types can't be equivalent.

They can't be equal, but they can be equivalent. A classic example is a type like optional<T>, which by nature can perfectly represent all possible values of T, so operator==(optional<T>, T) (and conversely operator==(T, optional<T>)) are well-defined for all possible values of T. There is one value of optional<T> that cannot possibly be contained by T, but that's still well-defined, it's just known to always return false. You can imagine all manner of other types where this can hold -- any case where one type is a strict superset of another, such as sum types or types with equivalent layout but strictly-larger-scale members (like a Point vs. Point). Where this doesn't hold, there probably shouldn't be an implementation of operator== between those types in the first place.

The principled approach to heterogeneous comparisons is to define x == y as C(x) == C(y), where C is the common type of X and Y, i.e. a type that can represent all values of X and all values of Y. But this (a) only shifts the question to "who decides C"

A common type does not need to represent all values of both types; only enough to determine equivalence. This usually means the "common type" is the smaller type, because a failure to convert the larger type to the smaller type inherently implies non-equivalence. As for "who decides it", this is usually the larger type, because the larger type is usually defined in terms of the smaller type and not the reverse, as I mentioned in another post.

and (b) doesn't at all work for any op== that doesn't follow the principled approach, such as boost::function::operator== (which considers x == y true when the boost::function x contains y, but for which x == x doesn't compile), or bind(f, _1) == v, which constructs a lambda expression that returns f(x) == v. (Or for _1 == v when using Lambda/Lambda2, for that matter.)

Both `bind(f, _1) == v` and `v == bind(f, _1)` should produce the equivalent lambda. (Not identical, perhaps -- one might `return m_f(m_x) == m_v` and the other might `return m_v == m_f(m_x)` internally, but these should be functionally equivalent. Or perhaps both do indeed return exactly the same implementation, and that's ok too.) If this is true, the commutative property has not been broken and this shouldn't break in C++20 regardless of which way it chooses to evaluate it. (And bonus: both orders will work even if you chose to only implement one of the two.) If that's not true, then I would argue that it's wrong and it should stop using operator== for that purpose. I'm not sure I sufficiently understand the boost::function case to comment on it.

There are tons of existing C++ code that works perfectly well without adhering to principled approaches to defining op==, and breaking this willy-nilly was irresponsible.

I would instead argue that implementing op== in an unprincipled manner was irresponsible in the first place. :) There are a lot more code-sanitizer, linter, and auto-rewriting tools around than in prior days, and these generally benefit from being able to make basic assumptions such as language-specified commutability not being violated. It's also less surprising to users.

On 20/02/2023 18:25, Peter Dimov wrote:

Defining "unprincipled" operator== overloads is common practice, typically such that x == y means x.something( y ). E.g.

struct none {};

class X { private:

int id_ = 0;

public:

explicit X( int id, ... );

bool operator==( int id ) const noexcept { return id_ == id; } bool operator==( none ) const noexcept { return id_ == 0; } };

or the already mentioned boost::function, which uses it to mean "contains". Whatever your definition of equivalence, X is neither equivalent to an int, nor to a 'none', and 'none' doesn't even have operator==.

I fail to see how that breaks commutability, or is incompatible with the C++20 changes, however. It just means it becomes legal to write `none{} == X{5}` when before you might have been forced to write `X{5} == none{}` if the author of X didn't implement the reverse operator.

On 2/20/23 08:47, Gavin Lambert via Boost wrote:

On 20/02/2023 18:25, Peter Dimov wrote:

...

Whatever your definition of equivalence, X is neither equivalent to an int, nor to a 'none', and 'none' doesn't even have operator==.

Regarding this point specifically, the author of X has indeed declared that X has an equivalence to int, by implementing that operator.

Being able to ask if `x == 4` inherently implies that `x` can somehow be equivalent to `4`.  If that equivalence is not intended to be implied, then it shouldn't have been defined.  (or perhaps a different type from `int` should have been used)

I think you're missing the point that operator== isn't always used to implement equivalence. This is also true wrt. other operators and their default function. We have a number of lambda libraries in Boost, as well as Boost.Proto and Boost.Spirit that wouldn't have existed if we followed your logic.

On 2/21/23 01:00, Gavin Lambert via Boost wrote:

On 21/02/2023 00:30, Andrey Semashev wrote:

...

I think you're missing the point that operator== isn't always used to implement equivalence. This is also true wrt. other operators and their default function. We have a number of lambda libraries in Boost, as well as Boost.Proto and Boost.Spirit that wouldn't have existed if we followed your logic.

No, I addressed that.  Even in lambda libraries, operator== should be used only for equivalence (as an indirection rather than directly), and as such it should still be commutative and agnostic of specific order. Assuming that, it shouldn't be broken by the C++20 changes.

In template expressions, operators are generally not commutative because the type of the result depends on types of the left and right arguments.

On 2/21/23 02:01, Steven Robbins via Boost wrote:

On Monday, February 20, 2023 4:45:33 P.M. CST Andrey Semashev via Boost wrote:

...

On 2/21/23 01:00, Gavin Lambert via Boost wrote:

...

On 21/02/2023 00:30, Andrey Semashev wrote:

...

I think you're missing the point that operator== isn't always used to implement equivalence. This is also true wrt. other operators and their default function. We have a number of lambda libraries in Boost, as well as Boost.Proto and Boost.Spirit that wouldn't have existed if we followed your logic.

No, I addressed that. Even in lambda libraries, operator== should be used only for equivalence (as an indirection rather than directly), and as such it should still be commutative and agnostic of specific order. Assuming that, it shouldn't be broken by the C++20 changes.

In template expressions, operators are generally not commutative because the type of the result depends on types of the left and right arguments.

Isn't the result of "==" always boolean?

The result can have any type. However, the rewritten candidates for operator== are only generated when the result is bool, so expression templates should be unaffected by this operator rewriting. I'm not sure about other comparison operators, though.

On 2/21/23 03:00, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

...

Isn't the result of "==" always boolean?

The result can have any type. However, the rewritten candidates for operator== are only generated when the result is bool, so expression templates should be unaffected by this operator rewriting.

That would have made too much sense. Have faith in the committee.

Instead, it's an error if a rewritten candidate doesn't return bool.

In that case, maybe I should file a gcc feature request to add an attribute preventing operator rewriting. Maybe then C++20 will be usable.

Mere moments ago, quoth I:

A common type does not need to represent all values of both types; only enough to determine equivalence.  This usually means the "common type" is the smaller type, because a failure to convert the larger type to the smaller type inherently implies non-equivalence.

Applying this to the optional<T> example used previously, the "common type" is T, and any failure to convert optional<T> to T can just return false, and this is perfectly correct. More generally, the "common type" would be the *intersection* between the two types (not the union, as you stated); any failure to convert either argument type to the common type can just return false, because if one value cannot be represented in the other type then they cannot possibly be equivalent. Assuming it doesn't fastpath out, you now have two values of the same common type that can use that type's homogenous operator==. It should not matter which order it compares these in, unless commutability has been violated. (For product types, you might need to repeat this for additional pairs of members, of course, but it can short-circuit as soon as there is a failure.)

On 17/02/2023 16:38, Jeff Garland via Boost wrote:

I'd dare to suggest we go one step further while we're here. We should join the 3 year cycle and drop support for c++11 in 2026, c++14 in 2029, etc. This gives users a planning window and understanding of where Boost is heading over time. And it matches what the standard is doing so it's already part of the bigger culture of evolution.

I think we should not mark drop dates depending on when a standard is released. IMHO we should put them depending on when fully conforming (core and stdlib) compilers were released in major platforms. For some standards, conforming compilers need extra time. Best, Ion