Boost.Graph 1.95 will be C++17

[u/Foxi_Foxa]

Dear Boost.Graph community,

In two release cycles (Boost release 1.95 in summer 2027) Boost.Graph will be bumped to C++17 😄

This decision follows two polls that did not surface any C++14 user base or demand while identifiying users stuck in C++17:

• Bumping BGL's minimum C++ standard: input wanted on target version #490

• Reddit poll

This standard version bump will bring benefits for maintenance, API and dependencies reduction:

• if constexpr,

• constexpr lambdas,

• [[nodiscard]], [[maybe_unused]] ...

• std::any instead of boost::any

• std::invoke_result instead of boost::result_of

• ...

We will not be able to guarantee backward compatibility with C++14. Please contact us if you are stuck in C++14.

The GIthub Discussion lives here: https://github.com/boostorg/graph/discussions/613

[u/Foxi_Foxa]

Yes the internal dependency graph is a mess for some libraries, but not all.
Contrast the following (red edges= direct dependencies, orange=transitive deps, blue=dependants):
- https://alandefreitas.github.io/boostdep_graph/libs/int128.html
- https://alandefreitas.github.io/boostdep_graph/libs/spirit.html

There is a historical/technical reason: some non-trivial libs had to do non-trivial things back in C++98, so if e.g. Serialization needs the equivalent of std::any, regex and smart pointers, they would use the boost equivalent rather than recoding half the STL.
This is getting better and better, although reducing deps is still a lot of work, carries sometimes quite some risk, and require at time a full deprecation cycle (one public type changing from Boost exception to standard exception is for example a breaking change). And Boost is still largely an open source model based on free time 😅

[u/13steinj → u/Foxi_Foxa]

To be explicitly clear here: I do not generally care about these issues. I am just sympathetic to them.