Subject: Re: [boost] New library proposal: Autodiff
From: Marc Glisse (marc.glisse_at_[hidden])
Date: 2018-12-19 20:40:15
(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
> 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:
> 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
Both introduce a strong bias towards more recent tools and standards.
-- Marc Glisse
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk