- take latest versions supported by the main compilers you work with, only considering their very latest version. You're talking about future so it's not the time to even consider non-latest compilers. And deduce standard C++ you case use from that
- don't ask yourself if you need latest usable standard, just use it, you don't want to spend again time to decide whether standard should be upgraded if you could have done it 3 years earlier for the same price
I'm not sure if this is directed generally at everyone participating in the discussion or directed at SFML's development. SFML isn't just a tool we use. There's no company or one entity behind SFML that would define what is required or not, instead we're dependent on the community and there are some who would be left behind if we just ignored C++ standards.
Sure, the argument can also be made the other way around, that not moving forward with the standard just means we're push other people away. But if that's the case, then that's their decision. Everyone can use SFML, whether you use a new standard or not, it's up to you to decide if it's a game breaker that the library doesn't use modern C++ internally. Where as if we just picked C++17, because I'm using it right now, many won't even be able to compile SFML anymore and it would not be their decision.
If you're just a consumer of libraries and C++ in order to build end user applications, then sure, just go with it, as long as your team/business allows it, but once you write code for others, you can't just ignore their requirements.
I'm quoting this entire post to give my post context.
Where as if we just picked C++17, because I'm using it right now, many won't even be able to compile SFML anymore and it would not be their decision.
Who is "many"? Have there been surveys to reflect who is using what standard/compiler? I'd be curious to know how many users of SFML are using legacy hardware/compilers.
Also; wouldn't using a compiler not up-to-date be a choice in the 99% of cases?
I think a decision shouldn't be based on assumptions.
But in our case, we really need to modernize the code base. The main advantage is easier maintenance, and consistency with new code (which will be written using modern C++). Writing unit tests first (which is what we're doing) will help there, to ensure no regression while rewriting the code.
This to me is the perfect answer.
