investigate removing boost

[tomjnixon]

Here's what we use, and what i would propose to do with them:

• math
  • factorial
    • could use std::tgamma, but it would be nice to know that it's exact for small values
    • implement ourselves as in boost -- have a table for small values (i.e. where there is no floating point round-off, up to 22), then fall back to std::tgamma (which is really unnecessary)
  • legendre
    • in c++17, could implement ourselves (or as a table)
  • constants (just pi)
    • std::numbers in c++20, implement ourselves
• algorithm/clamp - in c++17, implement ourselves
• make_unique - update to c++14
• optional - in c++17
• variant - in c++17

Optional and variant are the tricky ones. Some options for those:

• add a wrapper that makes it work with either boost or c++17
  • the behavior is a bit different so this may be tricky. This would be a pain to test, and we'd want to remove it eventually, which would be annoying again. It would also probably make the public interface unclear.
• update to c++17
  • it's 2023, and the features we need have been implemented for a long time in most compilers https://en.cppreference.com/w/cpp/compiler_support/17
  • quite a bit of code would be simpler, as the API for std::optional/variant is better than boost
• include our own implementations
  • similar issues to the first option. IME this is a pain, as implementations of these are quite subtle, and nobody is interested in maintaining them now that they have been standardised

[rsjbailey]

This sounds like a good idea.

• boost::math
  • looks mildly annoying to remove, but would likely cut > 1min off our CI cold build time, which for the sake of 2 functions and a constant seems a good trade-off if it doesn't cause problems. I'd probably do this even if we don't do anything else.
• boost::optional and boost::variant
  • given we don't use recusrive variants there's no advantage over the standardised versions other than compatibility with pre-C++17. I don't think implementing our own is a good idea for the reasons you've stated, and a wrapper/macro feels like a messy stopgap, so I guess keep boost or move to C++17?
• make_unique
  • IIRC it's a one-liner to implement anyway, but I think updating to c++14 makes sense as (I think, from memory) there's only a fairly narrow range of compiler versions that support 11 but not 14 as it was mostly a leftovers / bugfix release compared to 11 or 17.

I'm inclined to move to C++17, as you say there's been good support for a few years and the various developer surveys I've seen recently suggest a lot of the industry has moved or is planning to imminently. We're also developing other ADM related tools in later versions, so from an ecosystem point of view we're already relying on modern iterations of the language.

[tomjnixon]

Yeah, i agree in general.

In my mind the kind of people who are scared off by boost would also prefer broader compiler support, but that's not based on any data. I suppose the current state of the library will still be accessible.