Re: [boost] New library proposal: Autodiff

Subject: Re: [boost] New library proposal: Autodiff
From: Quentin Chateau (quentin.chateau_at_[hidden])
Date: 2018-12-19 21:13:28

I'm quite new to this mailing list and this topic is therefore very
interesting as it show the opinion of various people contributing to boost.

When I'm looking for a library for my - professional - projects, I tend to
put more interest into libraries that leverage new parts of the standard.
Firstly, it is a very good way to push for a more modern codebase and
improve my and my coworkers knowledge of a more future-proof way of using
C++. Don't underestimate the importance of learning. Secondly, people
dealing with old codebases are less likely to look for new libraries. They
usually mostly maintain code or refactor one piece at a time, but tend to
use already existing libraries, or internal ones: new libraries are used
for new, up-to-date projects. Don't develop stuff for people who don't need
it. Thirdly, if you wait for a standard to be mature to start developing
around it, it's going to be outdated by the time your library is fit for
production.

I'd be very interested to know what other, more experienced people think
about all this.

Obviously if new libraries are able to be compatible with more compilers,
it is a good thing, but remember that if we want to have people using
recent standards, then we have to make them relevant.

On Dec 19, 2018 21:40, "Marc Glisse via Boost" <boost_at_[hidden]>
wrote:

(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
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost