[gil] Phasing out support C++11 and switching to C++17
Hi, We're discussing [1] to start switching GIL to C++17 in the near future and, following Peter Dimov's policy on phasing out C++XY support [2], we'd like to: 1. Declare C++11 support deprecated in 1.75 (December 2020) 2. Drop C++11 support in 1.77 (?) (August 2021) Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective? [1] https://lists.boost.org/boost-gil/2020/10/0465.php [2] https://pdimov.github.io/articles/phasing_out_cxx03.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Gesendet: Montag, 26. Oktober 2020 um 10:37 Uhr Von: "Mateusz Loskot via Boost" <boost@lists.boost.org>
Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective?
Just a general comment from the perspective of a user (that is a user of boost in general, not boost-gil specifically). Part of declaring c++XX support deprecated should also be listing the concrete compilers whose support you are deprecating. E.g. I think the first c++17 bits have been implemented in gcc 6 and gcc 7 had mostly complete support, but it took till gcc 9 before the standard library gained support for pmr and to_chars is - to the bestof my knowledge - still not implemented for floating point types even in g++-10/11. Best regards Mike
Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, 26 Oct 2020 at 11:17, Mike via Boost <boost@lists.boost.org> wrote:
Gesendet: Montag, 26. Oktober 2020 um 10:37 Uhr Von: "Mateusz Loskot via Boost" <boost@lists.boost.org>
Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective?
Just a general comment from the perspective of a user (that is a user of boost in general, not boost-gil specifically). Part of declaring c++XX support deprecated should also be listing the concrete compilers whose support you are deprecating.
This is a good point.
E.g. I think the first c++17 bits have been implemented in gcc 6 and gcc 7 had mostly complete support, but it took till gcc 9 before the standard library gained support for pmr and to_chars is - to the bestof my knowledge - still not implemented for floating point types even in g++-10/11.
One of motivations is to drop support for GCC 5, It just seem simpler to assume C++17 as requirement with comment that some compilers w/ partial C++17 support may still work. It may also be possible to list required C++17 features per Boost (GIL) release, but that list may change in any next release, obviously. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr Von: "Mateusz Loskot via Boost" <boost@lists.boost.org>
On Mon, 26 Oct 2020 at 11:17, Mike via Boost <boost@lists.boost.org> wrote:
E.g. I think the first c++17 bits have been implemented in gcc 6 and gcc 7 had mostly complete support, but it took till gcc 9 before the standard library gained support for pmr and to_chars is - to the bestof my knowledge - still not implemented for floating point types even in g++-10/11.
One of motivations is to drop support for GCC 5, It just seem simpler to assume C++17 as requirement with comment that some compilers w/ partial C++17 support may still work.
The problem I see is: If you are pedantic, then there isn't a complete c++17 toolchain on linux yet. So unless you are saying, all current version of gcc/clang/libstdc++ "may still work" but are not really supported, you need to be more specific in what you require and support. Where support means (to me) "Will be regularly tested and will continue to work for the next couple of releases/years".
It may also be possible to list required C++17 features per Boost (GIL) release, but that list may change in any next release, obviously.
I wouldn't go there, because it isn't easy to actually verify that the documented features and the used features stay in sync and as a user, I also wouldn't appreaciate that mode, because at that point it would probably be easier for me to just try to compile your library and tests rather than corss-check the feature sets of my toolchain and your list manually. Just give me a stable lower bound on the officially supported toolchain and language versions. Of course all that doesn't mean that you can't add a note like "Other toolchains may work too" of course, but that is pretty much always the case anyway. Best Mike
Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, 26 Oct 2020 at 16:16, Mike via Boost <boost@lists.boost.org> wrote:
Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr Von: "Mateusz Loskot via Boost" <boost@lists.boost.org> On Mon, 26 Oct 2020 at 11:17, Mike via Boost <boost@lists.boost.org> wrote:
E.g. I think the first c++17 bits have been implemented in gcc 6 and gcc 7 had mostly complete support, but it took till gcc 9 before the standard library gained support for pmr and to_chars is - to the bestof my knowledge - still not implemented for floating point types even in g++-10/11.
One of motivations is to drop support for GCC 5, It just seem simpler to assume C++17 as requirement with comment that some compilers w/ partial C++17 support may still work.
The problem I see is: If you are pedantic, then there isn't a complete c++17 toolchain on linux yet.
GIL will not require feature-complete C++17 compiler We should be good with the last of the GCC 6 kind [1] or we may require GCC 7. The specifics will be decided as we go, as contributors will require. The deal is to announce C++11 phasing out early/now, to let ourselves time, at least two releases, but in practices it will be longer before we bump required compiler versions high.
So unless you are saying, all current version of gcc/clang/libstdc++ "may still work" but are not really supported, you need to be more specific in what you require and support. Where support means (to me) "Will be regularly tested and will continue to work for the next couple of releases/years".
Yes, we will aim to cover claimed support with CI and Boost regression tests matrix.
It may also be possible to list required C++17 features per Boost (GIL) release, but that list may change in any next release, obviously.
I wouldn't go there, because it isn't easy to actually verify that the documented features and the used features stay in sync
I made a mistake. Above I meant to write "Boost (GIL) release notes", where we can list GIL's required C++17 features for particular Boost release, just for user's convenience and change/remove that list from release notes in future. [1] https://gcc.gnu.org/legacy-ml/gcc/2018-10/msg00113.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 10/26/2020 11:49 AM, Mateusz Loskot via Boost wrote:
On Mon, 26 Oct 2020 at 16:16, Mike via Boost <boost@lists.boost.org> wrote:
Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr Von: "Mateusz Loskot via Boost" <boost@lists.boost.org> On Mon, 26 Oct 2020 at 11:17, Mike via Boost <boost@lists.boost.org> wrote:
E.g. I think the first c++17 bits have been implemented in gcc 6 and gcc 7 had mostly complete support, but it took till gcc 9 before the standard library gained support for pmr and to_chars is - to the bestof my knowledge - still not implemented for floating point types even in g++-10/11.
One of motivations is to drop support for GCC 5, It just seem simpler to assume C++17 as requirement with comment that some compilers w/ partial C++17 support may still work.
The problem I see is: If you are pedantic, then there isn't a complete c++17 toolchain on linux yet.
GIL will not require feature-complete C++17 compiler We should be good with the last of the GCC 6 kind [1] or we may require GCC 7. The specifics will be decided as we go, as contributors will require. The deal is to announce C++11 phasing out early/now, to let ourselves time, at least two releases, but in practices it will be longer before we bump required compiler versions high.
Worrying about gcc6 and/or gcc7, when the current release is gcc 10.2, seems a bit silly to me. I am not saying the current release(s) of gcc, clang, and vc++ are perfect in their support for C++17, but they should be good enough for any library wanting to target C++17. BTW wanting to target C++17 because it is "sexier", as opposed to having some feature(s) which the library wants to use, does not seem like a good reason to target any C++ level. I assume GIL wants to target C++17 because of the latter.
On Mon, 26 Oct 2020 at 19:17, Edward Diener via Boost <boost@lists.boost.org> wrote:
On 10/26/2020 11:49 AM, Mateusz Loskot via Boost wrote:
On Mon, 26 Oct 2020 at 16:16, Mike via Boost <boost@lists.boost.org> wrote:
Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr Von: "Mateusz Loskot via Boost" <boost@lists.boost.org> On Mon, 26 Oct 2020 at 11:17, Mike via Boost <boost@lists.boost.org> wrote:
E.g. I think the first c++17 bits have been implemented in gcc 6 and gcc 7 had mostly complete support, but it took till gcc 9 before the standard library gained support for pmr and to_chars is - to the bestof my knowledge - still not implemented for floating point types even in g++-10/11.
One of motivations is to drop support for GCC 5, It just seem simpler to assume C++17 as requirement with comment that some compilers w/ partial C++17 support may still work.
The problem I see is: If you are pedantic, then there isn't a complete c++17 toolchain on linux yet.
GIL will not require feature-complete C++17 compiler We should be good with the last of the GCC 6 kind [1] or we may require GCC 7. The specifics will be decided as we go, as contributors will require. The deal is to announce C++11 phasing out early/now, to let ourselves time, at least two releases, but in practices it will be longer before we bump required compiler versions high.
Worrying about gcc6 and/or gcc7, when the current release is gcc 10.2, seems a bit silly to me. I am not saying the current release(s) of gcc, clang, and vc++ are perfect in their support for C++17, but they should be good enough for any library wanting to target C++17.
Yes, indeed. I just explained that nobody there will die too hard for GCC 6, if it prevents use of a particular feature, etc.
BTW wanting to target C++17 because it is "sexier", as opposed to having some feature(s) which the library wants to use, does not seem like a good reason to target any C++ level. I assume GIL wants to target C++17 because of the latter.
We have more serious reasons indeed. e.g. to get rid of Boost.Iterator [1], possibly replace it with stl_interfaces [2] (but w/o investing time to go just C++14). [1] https://lists.boost.org/boost-users/2020/03/90323.php [2] https://lists.boost.org/boost-users/2020/03/90325.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 10/26/20 2:37 AM, Mateusz Loskot via Boost wrote:
Hi,
We're discussing [1] to start switching GIL to C++17 in the near future and, following Peter Dimov's policy on phasing out C++XY support [2], we'd like to:
1. Declare C++11 support deprecated in 1.75 (December 2020) 2. Drop C++11 support in 1.77 (?) (August 2021)
Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective?
[1] https://lists.boost.org/boost-gil/2020/10/0465.php [2] https://pdimov.github.io/articles/phasing_out_cxx03.html
Best regards,
Just out of curiosity, what new features and/or benefits (if any) will moving to conformance with C++17 add? Robert Ramey
On Mon, Oct 26, 2020 at 8:23 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
Just out of curiosity, what new features and/or benefits (if any) will moving to conformance with C++17 add?
just writing from the top of my head(will write details later), using C++17 GIL can be a stand-alone library. -- Thank you, Pranam Lashkari, https://lpranam.github.io/
On Mon, 26 Oct 2020 at 15:53, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/26/20 2:37 AM, Mateusz Loskot via Boost wrote:
We're discussing [1] to start switching GIL to C++17 in the near future and, following Peter Dimov's policy on phasing out C++XY support [2], we'd like to:
1. Declare C++11 support deprecated in 1.75 (December 2020) 2. Drop C++11 support in 1.77 (?) (August 2021)
Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective?
[1] https://lists.boost.org/boost-gil/2020/10/0465.php [2] https://pdimov.github.io/articles/phasing_out_cxx03.html
Just out of curiosity, what new features and/or benefits (if any) will moving to conformance with C++17 add?
e.g. make the library sexier for contributors who actually expressed interest in developing features for the library and who wish to use `-std=c++17` at least when they develop pull requests for the library. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Mon, Oct 26, 2020 at 8:38 AM Mateusz Loskot via Boost < boost@lists.boost.org> wrote:
On Mon, 26 Oct 2020 at 15:53, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/26/20 2:37 AM, Mateusz Loskot via Boost wrote:
We're discussing [1] to start switching GIL to C++17 in the near future and, following Peter Dimov's policy on phasing out C++XY support [2], we'd like to:
1. Declare C++11 support deprecated in 1.75 (December 2020) 2. Drop C++11 support in 1.77 (?) (August 2021)
Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective?
[1] https://lists.boost.org/boost-gil/2020/10/0465.php [2] https://pdimov.github.io/articles/phasing_out_cxx03.html
Just out of curiosity, what new features and/or benefits (if any) will moving to conformance with C++17 add?
e.g. make the library sexier for contributors who actually expressed interest in developing features for the library and who wish to use `-std=c++17` at least when they develop pull requests for the library.
Really, the stated reason for dropping support for C++11 is that it will make the library "sexier"? I understand that this would enable GIL to be compiled as a standalone library, and that's a good thing, but it would be better to provide that functionality and not break what currently works. Or at least take a stab at it and see how bad it is to support both. After all, Boost provides excellent support for workarounds and compiler compatibility.
On Mon, 26 Oct 2020 at 20:40, Emil Dotchevski via Boost <boost@lists.boost.org> wrote:
On Mon, Oct 26, 2020 at 8:38 AM Mateusz Loskot via Boost <boost@lists.boost.org> wrote:
On Mon, 26 Oct 2020 at 15:53, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/26/20 2:37 AM, Mateusz Loskot via Boost wrote:
We're discussing [1] to start switching GIL to C++17 in the near future and, following Peter Dimov's policy on phasing out C++XY support [2], we'd like to:
1. Declare C++11 support deprecated in 1.75 (December 2020) 2. Drop C++11 support in 1.77 (?) (August 2021)
Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective?
[1] https://lists.boost.org/boost-gil/2020/10/0465.php [2] https://pdimov.github.io/articles/phasing_out_cxx03.html
Just out of curiosity, what new features and/or benefits (if any) will moving to conformance with C++17 add?
e.g. make the library sexier for contributors who actually expressed interest in developing features for the library and who wish to use `-std=c++17` at least when they develop pull requests for the library.
Really, the stated reason for dropping support for C++11 is that it will make the library "sexier"?
No. I dodged the questions like those about the exact list of C++17 features.
I understand that this would enable GIL to be compiled as a standalone library, and that's a good thing, but it would be better to provide that functionality and not break what currently works. Or at least take a stab at it and see how bad it is to support both. After all, Boost provides excellent support for workarounds and compiler compatibility.
As I explained, one of major changes we will do is getting rid of Boost.Iterator (we already removed Boost.MPL, Boost.TypeTraits, and several more). Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
As I explained, one of major changes we will do is getting rid of Boost.Iterator (we already removed Boost.MPL, Boost.TypeTraits, and several more).
I think the questions that should be asked is a) "what will be of the most value to users?" b) "how will this expand the potential user base?" c) It the above are positive, the next question would be "how much effort would be required. So I generally answer the above by required the oldest version of C++ which supports the features that the library needs. This maximizes the breadth of the potential audience while minimizing the effort required. By the same token, if one isn't going to add features that users are requesting, there isn't much point in investing more effort in the library. So if it were me, I'd say - move it to C++ 11 or perhaps 14 to simplify the code, and maintenance, and leave moving to C++17 or higher when there will be some positive return on the effort. Robert Ramey
On Mon, 26 Oct 2020 at 21:58, Robert Ramey via Boost <boost@lists.boost.org> wrote:
As I explained, one of major changes we will do is getting rid of Boost.Iterator (we already removed Boost.MPL, Boost.TypeTraits, and several more).
I think the questions that should be asked is
a) "what will be of the most value to users?" b) "how will this expand the potential user base?" c) It the above are positive, the next question would be "how much effort would be required.
So I generally answer the above by required the oldest version of C++ which supports the features that the library needs.
Yes, that will be the case for GIL too. Simply, if 1) there are PRs with new features that are valuable to users and 2) implementation of those features uses C++17 and 3) nobody offers time to port those to C++11 (or it's not possible), then we have grounds to make the switch.
So if it were me, I'd say - move it to C++ 11
FYI, GIL moved to C++11 in Boost 1.68 (w/ removal of MPL, TypeTraits, Variant, etc.) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Mon, 26 Oct 2020 at 10:37, Mateusz Loskot <mateusz@loskot.net> wrote:
We're discussing [1] to start switching GIL to C++17 in the near future and, following Peter Dimov's policy on phasing out C++XY support [2], we'd like to:
1. Declare C++11 support deprecated in 1.75 (December 2020) 2. Drop C++11 support in 1.77 (?) (August 2021)
We are also considering, with Samuel, a less revolutionary approach: deprecate specific compiler/version in case it does not support certain C++11 features properly or suffers from bugs. For example, we may advertise dropping GCC 5 support due to issues similar to this https://github.com/boostorg/gil/pull/526 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Mateusz Loskot wrote:
We are also considering, with Samuel, a less revolutionary approach: deprecate specific compiler/version in case it does not support certain C++11 features properly or suffers from bugs. For example, we may advertise dropping GCC 5 support due to issues similar to this https://github.com/boostorg/gil/pull/526
If you drop GCC 5, you can make the minimum requirement C++14, as it's the default for GCC 6 and newer. (C++17 is default for GCC 11.)
On Tue, 27 Oct 2020 at 13:21, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Mateusz Loskot wrote:
We are also considering, with Samuel, a less revolutionary approach: deprecate specific compiler/version in case it does not support certain C++11 features properly or suffers from bugs. For example, we may advertise dropping GCC 5 support due to issues similar to this https://github.com/boostorg/gil/pull/526
If you drop GCC 5, you can make the minimum requirement C++14, as it's the default for GCC 6 and newer. (C++17 is default for GCC 11.)
Sounds fine too. I'll pass it to Samuel. Thanks. -- Mateusz Loskot, http://mateusz.loskot.net
On 10/27/2020 8:20 AM, Peter Dimov via Boost wrote:
Mateusz Loskot wrote:
We are also considering, with Samuel, a less revolutionary approach: deprecate specific compiler/version in case it does not support certain C++11 features properly or suffers from bugs. For example, we may advertise dropping GCC 5 support due to issues similar to this https://github.com/boostorg/gil/pull/526
If you drop GCC 5, you can make the minimum requirement C++14, as it's the default for GCC 6 and newer. (C++17 is default for GCC 11.)
I do not think that is a good argument for the minimum level of C++ a library decides to support. Programmers can always decide, if they wish, not to use the default level of a compiler. I do however see little wrong with dropping support for very old compiler releases when those releases do not implement correctly the minimum level of the C++ standard which a library targets.
Edward Diener wrote:
On 10/27/2020 8:20 AM, Peter Dimov via Boost wrote:
If you drop GCC 5, you can make the minimum requirement C++14, as it's the default for GCC 6 and newer. (C++17 is default for GCC 11.)
I do not think that is a good argument for the minimum level of C++ a library decides to support. Programmers can always decide, if they wish, not to use the default level of a compiler.
Yes, in theory, but there aren't many reasons to downgrade GCC 6 to C++11, as C++14 has very good backward compatibility.
participants (7)
-
Edward Diener -
Emil Dotchevski -
Mateusz Loskot -
Mike -
Peter Dimov -
Pranam Lashkari -
Robert Ramey