From: Mike (mike.dev_at_[hidden])
Date: 2020-10-26 15:16:18
> 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. 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 regards,
> Mateusz Loskot, http://mateusz.loskot.net
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk