Boost.Graph 1.95 will be C++17

[Becheler]

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:

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

This standard version bump will bring benefits for maintainance, 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.

[tinko92]

Dear Becheler, I am happy to see these modernizations. Boost.Geometry is currently depending on Boost.Graph for the biconnected component algorithm and headers related to using it (graph traits, adjacency list) and currently lists its baseline as C++14. There is some initial discussion about raising the baseline in the future as well, so I am not raising this as necessarily a problem, just to get a better idea what to expect and what to plan around.

Are there any more detailed plans on how this modernization will go, e.g. for new things first, or for certain interfaces first, etc.? I read that you stated there will be no backward compatibility guarantees, so I am just asking for your best guess whether those headers are likely to already be affected. This is to inform our own discussions/decisions about having to make a decision to raise our standard at 1.95 or later vs. reimplementing biconnected components locally, since we depend only on a very limited part of the library.

But I see for example, that biconnected_components.hpp includes depth_first_search.hpp, which includes named_function_params.hpp, which uses boost::result_of, which you name as a target for replacement by std::invoke_result.

[Becheler]

Hi @tinko92, thanks for reaching out, this is exactly the kind of downstream feedback we were hoping for 😄

To be transparent: nothing below is a promise. As you said, I'd rather give you hints than overcommit and send you down the wrong path, so I'll mostly explain why we think C++17 is the right direction.

The main plan is to continue our dependency reduction efforts. It is the number one complaint we hear from Boost users, and the perception of Boost as a blob of interdependent headers is the biggest barrier to adoption. For example, we lost a major bioinformatics project to a lightweight competitor because of the weight of our dependency chain, and potential users have told us outright they would rather rewrite BGL than drag all of Boost into their codebase.

So we are taking this very seriously. In the current release (1.93) we replaced a considerable number of Boost dependencies with C++14 equivalents, changing the transitive dependency chain for the best:

1.92	1.93

C++17 would allows us to go further. There is no finer grained ordering by interface yet: so far, dependency removal has been done one library at a time, project wide (e.g. #590), rather than header by header.

Here are the most relevant candidates (although without actual code proving it compiles all of this is a mere handwave 😅 ):

Dependency	Files	C++17 replacement	Notes
Boost.Tuple	24	std::tie, structured bindings	Mostly boost::tie on std::pair; graph_traits.hpp includes it and many users rely on that include
boost::result_of	5	std::invoke_result_t	Includes named_function_params.hpp
Boost.Optional	4	std::optional	Includes depth_first_search.hpp
Boost.MPL	28 uses	std::bool_constant, std::conditional_t, Mp11	Mostly in named parameters
Boost.TypeTraits	39	<type_traits>	Mechanical but wide
BOOST_STATIC_ASSERT	13	static_assert	Already in progress
Boost.Any	1	std::any	graphml.hpp
Boost.LexicalCast	2	std::to_chars, std::from_chars	graphviz.hpp, graphml.hpp

Unfortunately for you, the chain you traced is right on the front line:

• depth_first_search.hpp pulls Boost.Optional
• named_function_params.hpp pulls boost::result_of, Boost.MPL
• graph_traits.hpp pulls Boost.Tuple.
  Since BGL is header only, even purely internal changes mean any translation unit including these headers will need to be compiled as C++17. IIUC, detect_biconnected_components.hpp is reached from overlay/traverse.hpp, so in practice that would extend to most Boost.Geometry users?

Also be aware that we will likely drop the named parameters interface (bgl_named_params and the .weight_map(...) style chaining) by 1.95. or 1.96. From what I see, Boost.Geometry calls the positional overload biconnected_components(graph, component), which is not affected, so your call site should keep working.

For your decision, this means:

• 1.93 and 1.94 remain C++14 compatible, so nothing changes for you before summer 2027.
• If Boost.Geometry moves to C++17 at 1.95, I don't expect you'll need code changes on your side, since any change to the public API has to go through a two release deprecation cycle. Some Boost types leak through public interfaces, so swapping them for their C++17 equivalents can't happen in a single step.

Did I answer your question ?

Whichever way you go, I'm happy to coordinate, and please let me know if anything above would cause you trouble and if a path of less friction exists 🤗

[tinko92]

Thank you very much for the fast and detailed reply, that answers my question. 🙏

[tinko92]

A quick update for the purpose of coordination: Boost.Geometry decided to go for the C++17 baseline starting with 1.95 as well and deprecated C++14 with 1.93 boostorg/geometry#1496 . Thanks again for supplying the information that helped with making that decision so quickly.

[Becheler]

You are so welcome ! Let us know if we can help in any way 🤗

[jeremy-murphy]

Cool, I'm glad to hear that we're all moving forward together!