|
Boost : |
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-10-26 18:58:58
On Mon, 26 Oct 2020 at 19:17, Edward Diener via Boost
<boost_at_[hidden]> 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_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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk