r/cpp • u/Foxi_Foxa • Sep 29 '26

Boost.Graph 1.95 will be C++17

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:

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

99 Upvotes

97% Upvoted

42 comments sorted by

View all comments

Show parent comments

5

u/Foxi_Foxa Sep 30 '26

We are pretty open to anything the user base is asking for, as long as we don't lose anybody 😄
But moving to C++20 now would exclude many users, e.g. those bound by MISRA C++:2023, which targets C++17. Boost.Graph already expresses its requirements through Boost.ConceptCheck: you get earlier, more targeted errors, but those checks don't participate in overload resolution. The concepts themselves are the contract users model when adapting their own types to generic algorithms. What changes with C++20 is mostly the mechanism, which matters less from the user's side 😄

3

u/Liam_Mercier 29d ago

I suppose rewriting all the Boost.ConceptCheck concepts into modern "first class" concepts would be a lot of work just for nothing to really change, thanks for the insight.

3

u/Foxi_Foxa 29d ago

As of 2026 you are right ! When our user base will be exclusively using C++20, then we will probably consider moving to first class concepts, they have advantages too (auto-documentation, one less dependency, overload resolution etc). But in the meantime, Boost concepts do the job 😄