What I wrote almost 2 years ago:
When choosing a standard, we need to decide:
- Who are we targeting? Does our main user base have access to recent compilers?
- What newer C++ features can SFML directly benefit from?
- When would SFML 3 emerge?
The last point is important. If we were to choose C++14 at this very moment, it's already "outdated" by 4 years. Add to that the time until SFML 3 is ready.
And SFML 3 is still nowhere. So I'm no longer sure if this should be the criterion.
Would we even require a major version to add more modern C++ features?
A new C++ version
is a breaking change only w.r.t. old compilers, it's not breaking client code. Intuitively, it appears to me that a typical SFML user has access to an at most 3 years old compiler (to support C++17).
My suggestion:
- Start from C++17 -- it's old enough to have decent compiler support but also has helpful stdlib additions
- Include support from SFML 2.6 or (depending on time to implement) 2.7
- Use features mainly to add nicer APIs (move ctors, conversion from std::chrono/std::filesystem/...) and simplify internal implementations (lambdas, unique pointers)
SFML 2.6/2.7 could then be seen as a "proof-of-concept" of more modern features, and maybe based on that, we learn how to improve APIs for SFML 3.