On Mon, 26 Oct 2020 at 11:17, Mike via Boost wrote:

...

Gesendet: Montag, 26. Oktober 2020 um 10:37 Uhr Von: "Mateusz Loskot via Boost"

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

On Mon, 26 Oct 2020 at 16:16, Mike via Boost wrote:

...

Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr Von: "Mateusz Loskot via Boost" On Mon, 26 Oct 2020 at 11:17, Mike via Boost 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 Mon, 26 Oct 2020 at 19:17, Edward Diener via Boost wrote:

On 10/26/2020 11:49 AM, Mateusz Loskot via Boost wrote:

...

On Mon, 26 Oct 2020 at 16:16, Mike via Boost wrote:

...

...

Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr Von: "Mateusz Loskot via Boost" On Mon, 26 Oct 2020 at 11:17, Mike via Boost 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 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, 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 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.

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 Tue, 27 Oct 2020 at 13:21, 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.)

Sounds fine too. I'll pass it to Samuel. Thanks. -- Mateusz Loskot, http://mateusz.loskot.net

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.