Re: [boost] [gil] Phasing out support C++11 and switching to C++17

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