(since you know your position is unpopular, I'm sure you would be disappointed if noone replied ;-) On Wed, 19 Dec 2018, Vinnie Falco via Boost wrote:
- C++17 compiler that supports constexpr if statements. There are a fair amount of calculations done at compile-time which would require messy SFINAE hacks to make this C++14-compatible.
I know my position is unpopular, but I don't think this is a good tradeoff. Supporting C++11 certainly requires more work on the author's part but that is a finite investment.
Writing it may be a "finite" investment, but maintaining the resulting, way more complicated code is not. And I am not even counting the cases where this has an impact on the API.
The return on this is a practically unbounded amount of utility, as the number of users is normally expected to greatly outnumber the amount of authors (1 in this case). In fact you could argue that there is infinite utility in laboring to produce "messy SFINAE hacks", because otherwise users of C++14 and C++11 cannot use the library at all. Most users only care that the library works, and are unaffected by the particulars of the sausage-making.
Don't underestimate the importance of keeping the author of the library motivated. If supporting crappy old tools makes them lose the will to keep improving the library, we end up with one more unmaintained boost package...
In general, I feel like it is a good engineering practice for Boost libraries to only require C++14 or C++17 when absolutely necessary. In
Why stop at C++11? Why not stick to C?
this case it does not seem necessary. This year's developer surveys indicate that C++11 has the most widespread use:
https://www.jetbrains.com/research/devecosystem-2018/cpp/
https://isocpp.org/files/papers/CppDevSurvey-2018-02-summary.pdf
It seems like doing the more verbose C++11-style SFINAE is worth it, to have access to the larger base of C++ users. This opinion is my own, and I will note that (roughly speaking) the Boost library policy does not currently mandate support for any specific versions of C++.
The survey is about what people were using several months ago for all kinds of projects, including maintaining legacy code bases. However, we are interested in - what people will be using by the time the library has been reviewed and released (say a couple years) - projects that are likely to introduce a dependency to some new external library Both introduce a strong bias towards more recent tools and standards. -- Marc Glisse