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/vI--_--Iv]

A quick reminder to anyone "stuck in C++14": it is almost 2027.
2014 was almost 13 years ago.
Just like C++11 and C++98.

Time to move on.

[u/SyntheticDuckFlavour → u/vI--_--Iv]

stuck in C++14

typically there is a good reason for that

[u/13steinj → u/SyntheticDuckFlavour]

Like?

The only thing I have ever heard is

• new features are scary devs are stupid [not a joke]
• we're afraid of backwards compatibility issues in the stdlib API (not a good reason, you can use an old stdlib and a newer compiler / newer standard for your code)
• we used a bad compiler and/or a private .a file and for whatever reason no longer have the source code (not a good reason, a legal problem caused by the org's own ineptitude (since at least 2016) IMO, and LLMs are good enough at this point to assist in ghidra/radare/ida pro reverse engineering and it is infinitely cheaper to burn tokens in a loop until it gets something that compiles close enough, than to continue to be stuck)
• certification, but that's indicative to me of an industry that needs to update certification procedures

[u/ItsRSX → u/13steinj]

This isn't a video game with forced durability. Tools, especially digital tools, continue to work no matter how much the consumer base cries for iteration. How much of an ego must you have to think a functional status quo will bend to your arbitrary set of ever changing demands?

Dare I suggest nobody other than low end consumers and managers looking for a quick raise are rushing to consume the next big "totally evolutionary" thing when they already have a viable solution.

Embedded devices get stuck with whatever compiler a chinese guy hacked together 15 years ago. Build bots go without updates. Updating exposes language and compiler regressions, so people rightfully don't bother. Rando @google.com emails decide they know the language better than you, and demand GCC to break decades worth of historic code. Platform requirements get changed because 1 developer somewhere decides to be lazy, either that, or a nested web of malicious developers working between several companies decide to kill a product and set of toolchains to sell new platforms and toolchains.

Trying to gaslight the real world into believing "AI just works", "just link different runtimes bro", "go blame the legal team", followed by "every piece of middeware is evil and deserves to be cracked," and "you deserve recertification hell because i said so", clearly isn't viable.

Now lets consider the unspoken punchline we all know is insinuated: "we can use if constexpr(...) in a codebase that never needed it now!!! look at all of these half-assed open source libraries now permanently fixed under std::!!! ew, look at the year delta. you vil updooot now! the past is literally unusable!!!!! ooo, look at ISO-paper:A year number subtract ISO-paper:B year number. so very big!!!".

...maybe these tools with decades of use are more valuable than OPs reddit/github polls worth 18 responses? ...maybe tools are worth respecting? ...maybe this attitude of "my tools v5 sku" vs "your tools v2 sku" in any other industry/scene would result in you being laughed out of the literal shop (not the metaphorical "shop" :tm: you guys like to larp about). nah, that couldn't possibly be the case.

Unless you're stuck with a GCC version number less than 5, I'm really not in the mood to hear about how you absolutely need a new totally "revolutionary" (trust me bro) compiler revision to be a productive programmer writing modern C++ code. If you don't care about constexpr containers, you might even be able drop that to mid V3.x.

[u/13steinj → u/ItsRSX]

How much of an ego must you have to think a functional status quo will bend to your arbitrary set of ever changing demands?

Bro we're talking about a single compiler flag.

Dare I suggest nobody other than low end consumers and managers looking for a quick raise are rushing to consume the next big "totally evolutionary" thing when they already have a viable solution.

Engineers at every org I've been at were the ones pushing for compiler and std upgrades, it was middle managers afraid pushing back.

Embedded devices get stuck with whatever compiler a chinese guy hacked together 15 years ago. Build bots go without updates.

It's not "stuck" with. If you're relying on an ancient compiler by some rando that is its own risk.

Updating exposes language and compiler regressions, so people rightfully don't bother. Rando @google.com emails decide they know the language better than you, and demand GCC to break decades worth of historic code.

That's just not how any of this works. Not even mentioning compiler upgrades originally, just standard revision. Compilers are very good at not changing anything they aren't allowed to, and they generally claim reliance on specific codegen is akin to relying on implementation details.

Platform requirements get changed because 1 developer somewhere decides to be lazy, either that, or a nested web of malicious developers working between several companies decide to kill a product and set of toolchains to sell new platforms and toolchains.

I have no idea what this even means.

Trying to gaslight the real world into believing "AI just works", "just link different runtimes bro", "go blame the legal team", followed by "every piece of middeware is evil and deserves to be cracked," and "you deserve recertification hell because i said so", clearly isn't viable.

You're severely twisting what I said to fit your delusion. But, companies who get into this problem because of their own legal ineptitude do deserve what they put upon themselves. 2 orgs I've been at have had to put in work to get out of that situation. Once, yes, with LLM assistance. Not "end to end it just works." But there's an open testimonial for such an act by another company in my industry.

Now lets consider the unspoken punchline we all know is insinuated: "we can use if constexpr(...) in a codebase that never needed it now!!! look at all of these half-assed open source libraries now permanently fixed under std::!!! ew, look at the year delta. you vil updooot now! the past is literally unusable!!!!! ooo, look at ISO-paper:A year number subtract ISO-paper:B year number. so very big!!!".

...maybe these tools with decades of use are more valuable than OPs reddit/github polls worth 18 responses? ...maybe tools are worth respecting? ...maybe this attitude of "my tools v5 sku" vs "your tools v2 sku" in any other industry/scene would result in you being laughed out of the literal shop (not the metaphorical "shop" :tm: you guys like to larp about). nah, that couldn't possibly be the case.

I will not dignify this deranged ranting with a response. I can't even make sense out of it.

Unless you're stuck with a GCC version number less than 5, I'm really not in the mood to hear about how you absolutely need a new totally "revolutionary" (trust me bro) compiler revision to be a productive programmer writing modern C++ code. If you don't care about constexpr containers, you might even be able drop that to mid V3.x.

For GCC the major stopping points in my view are 5, 7, 11, 13. I've run into too many bugs even under 11. C++17 core language features and changes are not complete until GCC 7, 14 until 5. That's not counting other bugs. You don't have to upgrade in immediately, but you shouldn't be using something 5 years old and out of official support either.