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

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-10-26 18:17:04

On 10/26/2020 11:49 AM, Mateusz Loskot via Boost wrote:
> On Mon, 26 Oct 2020 at 16:16, Mike via Boost <boost_at_[hidden]> wrote:
>>> Gesendet: Montag, 26. Oktober 2020 um 11:41 Uhr
>>> Von: "Mateusz Loskot via Boost" <boost_at_[hidden]>
>>> On Mon, 26 Oct 2020 at 11:17, Mike via Boost <boost_at_[hidden]> 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.