How to decide when to increase the minimum supported C++ standard version?

Question

I'm maintaining a library written in C++, which offers modern-C++ bindings for another API that's C-ish (it's this one, although I'm trying to make this question somewhat more general).

Now, when I started working on this library, it was 2017. The newest published standard version was 2014, and 2011 was already popular, but not ubiquitous. I've stuck to requiring only C++11 and nothing above that, so far.

Now we're in 2023. The published standard is 2020, and C++2023 is feature-complete. I'm wondering - is it time for me to increase the minimum supported C++ language version? Naturally, this will let me simplify my API somewhat, and possibly forego bundling some code which has, since 2011, made it into the standard library (depending on whether I switch to C++14 or C++17 or even C++20).

Of course, the obvious detriment is that people using older versions of C++ will no longer be able to use my library. But - I have no idea how many; nor whether they'd be able to compensate somehow (e.g. downloading and building a newer compiler, upgrading their OS distribution etc).

So, my question to you: What considerations would you take into account when making such a decision? And - how would you try and estimate the incompatibility implications of this move?

PS - Assume the library's API is allowed to change with increasing versions.

Answer 1

Although you only ask in relation to a library, I will answer for both a library and an application and the considerations are slightly different.

In general, you should not update to a newer version of something until the benefits outweigh the costs.

In both cases, the benefit of switching to a new(er) version of the C++ standard is that you can make use of the features that were added to the language. As the C++ standardization effort is very much focused on maintaining backward compatibility, you don't really have to worry about features being removed.

Application

In application development, the costs associated with using a newer version of C++ center around the required tooling update and the familiarity of the developers with the new features.

If you do, or can introduce, regular compiler updates, then that cost is just part of the regular development costs.

What then remains is the familiarity with the new features. The developers will have to invest some time to know what features have been added, how those features work and how they can help them. But that doesn't have to be a big-bang cost. You can just gradually allow the use of new features.

Libraries

For libraries, the same costs apply as for applications, but there are some additional cost factors to consider in the form of your users.

Your user base may not be able to update their toolchain as easily as you can do it, especially if you also have users from a regulated industry (automotive, healthcare, etc.).

Also, if features from the new C++ standard make it into your API, then you have to consider how much of a learning curve it will be to use your new API.

If you don't know who your user-base exactly is, reach out to them. Make a very public announcement that you are planning to drop support for older C++ versions and invite everyone to respond to that plan.

In general, for libraries I try to keep the minimum required C++ version as low as possible to support as many users as possible.