Dropping C++03 support (again)
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.) 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.) This proposal should ultimately be approved and implemented by the Boost release managers; their opinions are particularly appreciated.
On Sat, 4 Feb 2023 at 13:08, Peter Dimov via Boost <boost@lists.boost.org> wrote:
I have a novel idea, let's drop C++03 support. [...]
* C++03 is 20 years old.
Happy Emerald Anniversary!
This proposal should ultimately be approved and implemented by the Boost release managers; their opinions are particularly appreciated.
If this doesn't happen this month, then it will have to wait until February 2033, I guess. Hurry! ;) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
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
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....
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 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 <type_traits> support is broken. We don’t have any Clang earlier than 5 in the CI system either. Matt
On Sat, Feb 4, 2023 at 8:52 AM Matt Borland via Boost <boost@lists.boost.org> 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 <type_traits> 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 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
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. Cheers, Kostas
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 2023-02-04 at 13:08, Peter Dimov via Boost wrote:
Greetings,
I have a novel idea, let's drop C++03 support.
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.
An equally daring proposal: Call in Boost 2.0 to mark the beginning of a new epoch.
On Sat, Feb 4, 2023 at 7:08 AM Peter Dimov wrote:
This proposal should ultimately be approved and implemented by the Boost release managers; their opinions are particularly appreciated.
We're having the release manager discussion about this off the list but I just wanted to let people know that we are discussing it. I am personally in favor of: - No longer letting C++03 failures block the release - This means giving those core Boost libraries (that are just keeping C++03 support because other Boost libraries depend on them) the freedom to drop C++03 support. I think we would wait at least two versions from the announcement, i.e. at least after Boost 1.83 for the first Boost release where we drop the support. This for both: Those distributions that ship Boost and update their Boost version every 6 months or so, and: Giving authors that extra time to get whatever they want in for the final "C++03 supporting" Boost. The major version number increment when we do this is also appealing to me. A further idea which was raised off list, and worth hearing the developer community's opinion on, is: - 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 libraries who do not have active maintainers would not opt in, and would not ship in Boost 2. Glen
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2/4/23 16:26, Glen Fernandes via Boost wrote:
On Sat, Feb 4, 2023 at 7:08 AM Peter Dimov wrote:
This proposal should ultimately be approved and implemented by the Boost release managers; their opinions are particularly appreciated.
We're having the release manager discussion about this off the list but I just wanted to let people know that we are discussing it.
I am personally in favor of:
- No longer letting C++03 failures block the release - This means giving those core Boost libraries (that are just keeping C++03 support because other Boost libraries depend on them) the freedom to drop C++03 support.
I think we would wait at least two versions from the announcement, i.e. at least after Boost 1.83 for the first Boost release where we drop the support. This for both: Those distributions that ship Boost and update their Boost version every 6 months or so, and: Giving authors that extra time to get whatever they want in for the final "C++03 supporting" Boost.
The major version number increment when we do this is also appealing to me. A further idea which was raised off list, and worth hearing the developer community's opinion on, is:
- 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 libraries who do not have active maintainers would not opt in, and would not ship in Boost 2.
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. So, in my opinion, all libraries must be in 2.x by default. Any exceptions to that should be discussed individually.
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 2/5/23 12:09, Rainer Deyke via Boost wrote:
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.
There are different kinds of breakage. One is having to update Boost library names in the linker command line. Another is having to rewrite code that used Boost features that are no longer available, with the potential to introduce a bug in the process. I'm fine with the former, but not the latter.
On 4. Feb 2023, at 14:34, Andrey Semashev via Boost <boost@lists.boost.org> 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?
On Sat, Feb 4, 2023 at 5:27 AM Glen Fernandes via Boost <boost@lists.boost.org> wrote:
- 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 libraries who do not have active maintainers would not opt in, and would not ship in Boost 2.
As long as Boost.Asio and Boost.Coroutine opt-in, I'm OK with this. Thanks
sob., 4 lut 2023 o 15:00 Vinnie Falco via Boost <boost@lists.boost.org> 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 <boost@lists.boost.org> 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
On Sat, Feb 4, 2023 at 7:06 AM Andrzej Krzemienski <akrzemi1@gmail.com> 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
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 <akrzemi1@gmail.com> 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
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 <boost@lists.boost.org>:
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 <akrzemi1@gmail.com> 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
On Sat, Feb 4, 2023 at 7:41 AM Klemens Morgenstern via Boost <boost@lists.boost.org> wrote:
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.?
We should probably stick to doing one thing at a time, and see where we are when the dust settles first, before taking on new major decisions. Thanks
But what happens with asio's boost::spawn()? 04.02.2023 16:08:40 Vinnie Falco via Boost <boost@lists.boost.org>:
On Sat, Feb 4, 2023 at 7:06 AM Andrzej Krzemienski <akrzemi1@gmail.com> 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
Chris introduced a new set of spawn overloads (that use a completion signature) that only depend on context. The other ones still depend on coroutine, but they are deprecated. On Sun, Feb 5, 2023 at 1:36 AM oliver.kowalke--- via Boost < boost@lists.boost.org> wrote:
But what happens with asio's boost::spawn()?
04.02.2023 16:08:40 Vinnie Falco via Boost <boost@lists.boost.org>:
On Sat, Feb 4, 2023 at 7:06 AM Andrzej Krzemienski <akrzemi1@gmail.com> 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
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.
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? Robert Ramey
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.
niedz., 5 lut 2023 o 01:29 Peter Dimov via Boost <boost@lists.boost.org> 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, and Boost.TypeTraits decide tos remove the code for C++03 compatibility, then Boost.Serialization loses C++03 compatibility also. Regards, &rzej;
On 2/4/23 11:05 PM, Andrzej Krzemienski via Boost wrote:
niedz., 5 lut 2023 o 01:29 Peter Dimov via Boost <boost@lists.boost.org> 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
On Sun, 5 Feb 2023 at 18:15, Robert Ramey via Boost <boost@lists.boost.org> wrote:
The proposal is not to drop 03 support - whatever that means. The proposal is to deprecate and remove a few older boost libraries [...] I still don't see what benefit obtains though.
If I take the liberty to sort your own sentences as below, then it becomes a logical sequence that, I believe, can help to see the benefit: 1. The proposal is not to drop 03 support - whatever that means. 2. I still don't see what benefit obtains though. 3. The proposal is to deprecate and remove a few older boost libraries The 3. is the answer. Whatever we call it, Boost surely will benefit from removal of the old libraries, where the term old happens to coincidence with C++03. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
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.
Peter's proposal is very minimal and should be uncontroversial. If we increase the scope, it will stop being uncontroversial. Let's not turn this into Python 3 transition. вс, 5 февр. 2023 г., 21:04 Peter Dimov via Boost <boost@lists.boost.org>:
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sun, 5 Feb 2023 at 19:04, Peter Dimov via Boost <boost@lists.boost.org> 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
niedz., 5 lut 2023 o 19:02 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
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.
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). 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. Are the above statements correct? Regards, &rzej;
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 1:25 PM, Christian Mazakas via Boost wrote:
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.
Nothing in boost requires that you support C++03. IIRC the only requirement is that you support the most recent version of C++. Due to C++ policy on backward compatibility, this usually happens automatically so people forget about it.
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.
You could obtain this benefit tomorrow. Just set the policy for the library you maintain.
- Christian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 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
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
On 6. Feb 2023, at 01:18, Robert Ramey via Boost <boost@lists.boost.org> wrote:
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.
Those are good laws. My personal variant of the first law is: If it is not tested, (assume) it is broken.
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.)
On 2/5/23 3:41 PM, Peter Dimov via Boost wrote:
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.)
Boost.X can remove the support for C++03 in 1.83, without going
The Boost Safe Numerics Library requires C++14 or above and always has. I'm not aware that this violates any Boost policy. through the deprecation procedure. I'm not aware that removing support for C++03 is "deprecation" nor that doing such a thing would require any sort of "deprecation procedure". That is not to say that it would nice for a maintainer to give some notice - but I'm not aware of any requirement.
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 <boost@lists.boost.org> 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
Peter Dimov via Boost <boost@lists.boost.org> writes:
I have a novel idea, let's drop C++03 support.
I think it's a great idea. I would also be in favor of bumping the major version to 2 and potentially dropping unmaintained/obsolete libraries though I also appreciate that this is a more drastic change that may sink the whole idea. Also, one benefit of 2.0.0 that I believe was not mentioned is outside perception. If it's 1.83.0 then I don't think it will be easy to convince the wider audience that it's anything other than the "same old" Boost even if there are drastic changes like dropping of unmaintained/obsolete libraries or better modularity. (And if anyone here wonders, the perception in the wider audience is not very good, at least IME).
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. I believe a better approach would be to name the minimum supported versions for the main three C++ compilers (GCC, Clang, and MSVC) which then determines the practically usable set of C++ features.
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.)
On 2/6/23 16:40, Peter Dimov via Boost wrote:
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.
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. That said, many libraries already did list compiler versions before. And we also had libraries that didn't support C++03, and we had some libraries raise their minimum C++ version requirement during their lifetime, so I'm really not sure what exactly this proposal is bringing. I sure hope that it is not that libraries supporting C++03 are now banned somehow.
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.
Peter Dimov via Boost <boost@lists.boost.org> 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.
(MSVC 14.3 is VS2022, not VS2015.)
Yes, you are right, of course.
Boris Kolpackov wrote:
Peter Dimov via Boost <boost@lists.boost.org> 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.
On 06/02/2023 17:14, Peter Dimov via Boost wrote:
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.
Then the reason that we should not support C++03 because is 20 years old is not a very good reason. The epoch should be set on how old the oldest compiler that fulfills the minimum requirements of C++11 is. E.g. GCC 5 was released 8 years ago, and I think Ubuntu 16.04 (released on 2016) was the first Ubuntu release to have GCC-5 as the default compiler. A lot of years, but certainly not 20. Maybe requiring support for all the language features or the standard library is not strictly necessary. Even two-phase lookup was first implemented in Visual Studio in VS 2017 and the C preprocessor in VS2019! We should set minimum versions of compilers that we should support and make sure we can test on those. Best, Ion
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 <type_traits> 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
Matt Borland wrote:
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 <type_traits> 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.
That's not entirely true. <type_traits> 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... 4.8 is not a C++11 compiler for other reasons though; its <regex> is completely broken. On the other hand, I'm not sure that <regex> can ever be considered not completely broken.
That's not entirely true. <type_traits> 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
On 08/02/2023 17:30, Matt Borland via Boost wrote:
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 <type_traits> 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.
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-... Best, Ion
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 Sat, Feb 4, 2023 at 7:08 AM Peter Dimov via Boost <boost@lists.boost.org> 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. -- David
On 15. Feb 2023, at 21:15, David Sankel via Boost <boost@lists.boost.org> wrote:
On Sat, Feb 4, 2023 at 7:08 AM Peter Dimov via Boost <boost@lists.boost.org> 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.
On Fri, 17 Feb 2023 at 13:06, Hans Dembinski via Boost <boost@lists.boost.org> wrote:
On 15. Feb 2023, at 21:15, David Sankel via Boost <boost@lists.boost.org> wrote:
On Sat, Feb 4, 2023 at 7:08 AM Peter Dimov via Boost <boost@lists.boost.org> 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.
I second that too. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Sat, Feb 4, 2023 at 5:08 AM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Greetings,
I have a novel idea, let's drop C++03 support.
Please, please, please -- let's do this finally. I've said for a decade that people that need support for older versions, can just use older versions of Boost. If you really need some newer library update in an older version then go do it yourself or pay someone to do it for you. I will note that the last survey I recall by the C++ Foundation showed the vast majority of c++ projects use C++11 or above. w.r.t 1.x versus 2.x -- let's leave it 1.x so as not to perturb the bigger ecosystem of packagers. 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. Thanks for bringing this up Peter. Jeff
On Fri, Feb 17, 2023 at 7:38 AM Jeff Garland via Boost <boost@lists.boost.org> 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
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 <vinnie.falco@gmail.com> wrote:
On Fri, Feb 17, 2023 at 7:38 AM Jeff Garland via Boost <boost@lists.boost.org> 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 8:17 AM Jeff Garland <azswdude@gmail.com> 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. 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.
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 would even question the assumption that op<=> represents progress. This is an example where the purported benefits are likely not worth the cost. The whole thing seemed to me to be a public relations maneuver. Regardless of how "difficult" the fixes are, a key objective of new C++ standards is to not break existing programs. I expect the frequency of breakage to only increase with time, as the activities of the committee deviate more and more with the original function of ISO bodies: "ISO is supposed to (a) rubber-stamp existing de-facto standards, (b) provide a "safe space" for major industry players to negotiate a standard without violating antitrust laws"
...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.
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. When a successful organization loses its founders without solving the "succession problem" (https://samoburja.com/the-succession-problem) it can stop being a live player. Boost was a live player when it led useful and successful additions to the standard (C++11). But when Boost's founders stepped back (for the known reasons) the innovation slowed, and WG21 was seen as the preferred vehicle for achieving progress.
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.
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. 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/) * 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 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
On Fri, Feb 17, 2023 at 9:38 AM Dominique Devienne <ddevienne@gmail.com> wrote:
...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.
Yes, 100% ! But... we're not talking about limiting ourselves to C++11, we are talking about *supporting* C++11. Libraries can always use newer C++ features if they want to. For example I provide deduction guides when compiling under C++17 and later. An Beast comes with examples that use co_await. "Supporting C++11" just means that the release managers will test the libraries that claim to work under C++11, using C++11 compilers. A library is still free to require C++14 or any later version of C++ if it wants to. I support C++11 because it does not cost me much to do so, and because there are still a considerable number of users who need it. That number is shrinking, and when it gets too small I will probably switch to C++14 or C++17 as my minimum supported version. But I will not do it every 3 years just because that's how the standards committee does it. I will do it when the cost/benefit analysis favors it. Thanks
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 <vinnie.falco@gmail.com> wrote:
On Fri, Feb 17, 2023 at 8:17 AM Jeff Garland <azswdude@gmail.com> 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 <azswdude@gmail.com> wrote:
C++23 will blow your mind then -- no significant language features were added.
Junk was added to the stdlib though.
I'll take that as a personal jab :)
Not a jab I was talking about Beman and I didn't want to bring up the reason for his departure.
...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
The metric I use, is what percentage of potential users will be lost if C+11 is dropped.
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.
Well, "most" could be 51%. Even if if 80% of my users are on 14 or above, I would not drop support for 11. But yes if in 3 years I could drop 11 and only 5% of potential users would be lost then I would probably drop it. Unfortunately we are not quite there yet. Reference: <https://isocpp.org/files/papers/CppDevSurvey-2022-summary.pdf>
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.
That's all being worked on including the license (CPPA is taking care of that) so when it is delivered I'm pretty sure it will make everyone happy. This replaces Doxygen. But if people want to keep using Doxygen, that also works.
I retract my suggestion. Instead let's litigate deprecation on an ongoing basis instead.
Yes that does sound entirely reasonable and sensible :) Thanks
On Fri, Feb 17, 2023 at 10:11 AM Jeff Garland <azswdude@gmail.com> 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 17. Feb 2023, at 17:49, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
* 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/)
I am looking forward to this, Vinnie. I am very unhappy with the current boostbook/doxygen situation.
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.
Andrey Semashev 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 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.
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
Jeff Garland wrote:
On Fri, Feb 17, 2023 at 11:01 AM Peter Dimov via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org> > wrote:
Andrey Semashev 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 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.
As I said, it fixes some cases, but not others. This whole idea of x == y necessarily being equivalent to y == x in the heterogeneous case (in C++ code) is misguided, but the rewritten candidate being preferred to the non-rewritten one when better match is just... You'd think the committee wouldn't be so eager to deliberately break code. "This code was already broken!" Yeah, right. Very nice of you to decide that for me.
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.
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 2/20/23 01:48, Gavin Lambert via Boost wrote:
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.
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.
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. Sometimes it seems the Committee just assumes the world will momentarily upgrade to the latest C++ standard and all legacy code cease to exist.
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.
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 these to be non- commutative, outside of pathological library-fights.)
Why is this "pathological"? If you allow heterogeneous comparisons, who decides the meaning of x == y, the author of x or the author of y? The unspoken convention in C++ is "the left hand decides". Because there needs to be a convention. Why the left hand side? Because (a) it's natural and (b) if you use member operator==, that's what happens.
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
Steven Robbins 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. But the question "who decides the meaning of x == y" doesn't have anything to do with equivalence anyway. You have to have an answer to it. 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" 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.) 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.
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<int32_t> vs. Point<int64_t>). 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.
Gavin Lambert wrote:
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. :)
That's not for you to decide. Some programmer has implemented op==, it's worked for him perfectly well. You are not a party to the transaction. It's traditionally not been C++'s philosophy to dictate the meaning of overloaded operators. There are style guides, sure. These are precisely that, style guides. 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==.
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 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) This does *not* mean that an X is-a int, or even that it can be converted from or to an int -- those are separate operations. But it is -- somehow -- able to answer if it is currently equivalent to an int or not. That is precisely what defining the operator means.
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 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.
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 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? I'm still having a hard time understanding in what "non pathological" circumstances it makes sense for this operator NOT to be symmetric? -Steve
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.
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.
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.
On Mon, Feb 20, 2023 at 2:01 PM Gavin Lambert via Boost <boost@lists.boost.org> wrote:
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.
Are you perchance acquainted with the "midwit meme?" Thanks
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 20/02/2023 12:08, Peter Dimov 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 these to be non- commutative, outside of pathological library-fights.)
Why is this "pathological"? If you allow heterogeneous comparisons, who decides the meaning of x == y, the author of x or the author of y?
The correct answer is usually "whichever type was created last" (or more correctly, whichever one most naturally can depend on the other) and is thus aware of the other and capable of providing the appropriate conversion/comparison, either directly in the equality operator or via conversion operators (though the latter have their own sets of problems). This has historically been a bit more problematic in C++ libraries with insufficiently-constrained template code, because until Concepts, constraining was a lot harder, so many types didn't bother, or used techniques that are more problematic with the current standard wording (e.g. return-type SFINAE). Applications are more likely to use concrete types, so are less vulnerable to this. Basically, operator==(A,B) and operator==(B,A) should both be defined by A, neither by B. That means that if one implements the single-parameter instance method it should also implement the two-parameter reversed friend (and *not* leave that to the other class's instance). This is a natural rule anyway, because trying to do otherwise creates mutual dependency loops. If A knows about B then B should not know about A. (You could often get away with that before when A and B are from the same library, but that's still a mutual dependency loop, which often requires implementation hoops.) The main things C++20 brings to the table are to allow (but not require) only one of the operator== to be implemented and not require operator!= to be implemented, which simplifies the code. Unless these have pathological implementations, you shouldn't care which one it chooses to actually call (if you do define more than one), since they should all produce the same result. If there are significant performance differences between them, then perhaps you shouldn't implement the one that has worse performance, or spell it differently from operator== as a hint to the user that it's a more expensive operation, so they don't use it accidentally. The only other reason I can think of to have order-sensitive behaviour of supposedly commutative operators is if you're abusing the operator overloading for a compiled DSL... but arguably operator== still ought to be commutative in a DSL, or you're probably being more abusive than you should be.
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
On Sat, Feb 4, 2023 at 6:08 AM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Greetings,
I have a novel idea, let's drop C++03 support.
+1 I think we have enough consensus to go ahead with this plan now. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
On Sat, Feb 4, 2023 at 6:08 AM Peter Dimov via Boost <boost@lists.boost.org> 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...
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.)
This proposal should ultimately be approved and implemented by the Boost release managers; their opinions are particularly appreciated.
Here you go.. <https://github.com/boostorg/website/pull/729>
On 2/4/23 4:08 AM, Peter Dimov via Boost wrote:
Greetings,
I have a novel idea, let's drop C++03 support.
What I don't understand is how we're supporting C++03 now. From https://pdimov.github.io/articles/phasing_out_cxx03.html#_ongoing_costs_of_m... Summary We need a policy on phasing out C++03 support in Boost. C++03 support is holding us back. It impedes development, increases maintenance costs, increases dependencies, and increases compilation times. "Library authors and maintainers need to have an approved mechanism for dropping C++03 support in their libraries." Authors and maintainers have never been required to support any version of C++ other than the most recently released one. "I thought library authors were free to only support C++17?" This is Boost policy for new library submissions. It’s obviously unworkable for old and established libraries (that are currently in maintenance mode) on which many other libraries depend, both in Boost and outside of it." For the most part C++ versions maintain backward compatibility with older versions. So if a library is accepted while the latest C++ version is C++17 and then C++20 comes out, then the library still works fine. So there is nothing to do. For example, Boost is a dependency of hundreds, if not thousands, Debian packages. We have a responsibility to not break them unnecessarily. "Why not use C++11 only if available?" In addition to increasing maintenance costs, this also creates other problems. Let’s consider the scenario in which a Boost library uses, for example, std::function under C++11 and boost::function under C++03. namespace lib1 { #if CXX11 using std::function; #else using boost::function; #endif struct lib1_type { function<void()> f_; }; } // lib1 It’s common, at least under Linux, for user code to use a system-provided Boost (which is often compiled under C++03), and to use f.ex. C++14 or even C++17 itself. This means that lib1_type will have different definitions in the precompiled Boost library and in user code, which leads to hard to track undefined behavior. To avoid these problems, lib1 should always use std::function. Actually to avoid these problems, we should encourage uses to compile the boost library from the latest source with the compiler they are going to use to build their application. (aside, they should be encouraged to run the test suites of the libraries they are going to use as well. FYI - I'm still conflicted as to whether for some given functionality, I should prefer standard library components or the corresponding boost components. Ongoing Costs of Maintaining C++03 Support Impeded Development "If a library supports C++03, contributions that use C++11 features have to either be rejected, or have C++03 workarounds applied to them." Currently a the maintainer is permitted to select which of these methods is most suitable in a given circumstance. Nothing more is needed. "Since C++11 features such as variadic templates and perfect forwarding significantly increase productivity, this slows down the pace of development." Productivity for whom? The library maintainer can now decide whether to upgrade to newer components or just do nothing. Its up to him and fine either way. "Increased Maintenance Costs Even libraries in maintenance mode need to be updated to support newer standards, and C++03 code is significantly costlier to change due to, f.ex. use of the preprocessor to emulate variadic templates and use of numerous overloads to emulate perfect forwarding." "Again, currently maintainers can decide among these tradeoffs." In addition, C++03 compilers are generally older and have more quirks and issues that need to be worked around. Again, currently maintainers can decide among these tradeoffs. "Increased Dependencies Libraries that support C++03 have to use Boost components even when a corresponding standard library component exists in C++11. Examples are std::function, std::bind, std::tuple, std::shared_ptr, <type_traits>, std::fpclassify, and so on." I'm conflicted as too whether std components are better than boost components. I don't see the benefit of enforcing either preference on library maintainers. Increased Compilation Times One common complaint against Boost is high compilation times. Nearly all such objections can be traced to use of either the preprocessor library or Boost.MPL, and the reason is that without variadic templates, a high number of overloads or specializations need to be generated and parsed. Again, currently maintainers can decide among these tradeoffs. Compilation time is not a huge problem for boost components except for users who don't understand how to properly factor code into source files. Trying to help these people is beyond the reach of our efforts. "If we require C++11 ..." We're currently required a recent standard for new libraries. As far as I know, all boost libraries currently meet that standard - even those written 20 years ago and haven't had much maintenance. "Suggested Policy A library author or maintainer will be allowed to announce that C++03 support in the library is deprecated." A library author or maintainer has never been required to support any specific version of C++ other than the most recent one. Such a policy is already in place and has never been required. "This announcement will take the following forms:..." a) Restate that all boost C++ libraries are required to build and run with the latest available version of C++. b) Terminate testing of Boost libraries with versions of C++ earlier than C++14? or whatever. "A note in the documentation;" Include restatement/reemphasis of traditional boost policy as stated above. "A message issued at compilation time if a library header is included in C++03 mode." I don't know what this means. If a header is included in source file being compiled by a compiler set up to compile C++03 ? or if the source code only compiles with C++03?(not much code falls in here), or what? "The recommended form of the code issuing the message will be ..." if there is no change in the code that happens to supports C++03 why would any message be necessary? If the code has been changed so that it requires support for a more recent compiler version than before, then the following message is recommended. #include <boost/config.hpp> #include <boost/config/pragma_message.hpp> #if defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES)) BOOST_PRAGMA_MESSAGE("Compiler support for variadic templates required") #endif At least two Boost releases must ship with a deprecation notice whenever such library changes are made. ===================================== Reiterating the above action plan: a) Restate that all boost C++ libraries are required to build and run with the latest available version of C++. b) Terminate testing of Boost libraries with versions of C++ earlier than C++14? or whatever. Just invoke the above two actions right now. No authority is required as they don't represent any change in traditional Boost Policy. This will save us a ton of time. Robert Ramey
participants (28)
-
Andrey Semashev -
Andrzej Krzemienski -
Bo Persson -
Boris Kolpackov -
Christian Mazakas -
David Sankel -
Dominique Devienne -
Gavin Lambert -
Glen Fernandes -
Hans Dembinski -
Ion Gaztañaga -
jack -
Jeff Garland -
John Maddock -
Klemens Morgenstern -
Kostas Savvidis -
Mateusz Loskot -
Matt Borland -
oliver.kowalke＠gmail.com -
Peter Dimov -
Rainer Deyke -
René Ferdinand Rivera Morell -
Robert Ramey -
Steven Robbins -
Tom Kent -
Vinnie Falco -
Zach Laine -
Дмитрий Архипов