sf::Time and chrono library
To keep SFML simple, explicit but up-to-date with the features of the STL, the introduction/integration of <chrono> would be of help to some.
sf::Time is a simple self-contained class, therefore, does not (yet) allow the chrono literal conversions, operator overloads, etc.
I propose to carefully define/discuss an extended API for sf::Time (and sf::sleep function) that extends sf::Time by the chrono library. Moreover, since <chrono> would be included already, sf::Time could possibly benefit from it internally (unsure of that though).
New allowed conversions and overloads:
// Currently
sf::Time t1 = sf::milliseconds(1001);
// Extended capabilities after e.g., using namespace std::chrono_literals;
sf::Time t2 = 1001ms;
sf::Time t3(1001ms);
sf::Time t4 = 1s + 1ms;
t1 += 1ms;
// Resulting type: sf::Time or std::chrono::duration?
// How about sf::Time with implicit conversion to chrono?
auto t5 = sf::seconds(1) + 1s;
Integrating Chrono makes sense only partially as it itself is very flexible but with some serious drawbacks. Consider these two examples readability- and convenience-wise:
/* Example 1 */
using namespace sf;
Time t = milliseconds(1001);
std::cout << "Time: " << t.asSeconds() << " second(s)\n";
// Output: Time: 1.001 second(s)
/* Example 2 */
using namespace std::chrono;
duration t = milliseconds(1001);
std::cout << "Time: " << duration<float>(t).count() << " second(s)\n";
// Output: Time: 1.001 second(s)
Chrono is more explicit so for a library developer it is quite useful to know what is/isn't going on but the user is bloated with unnecessary information. However, carefully providing chrono extensions could synergize well with other modern libraries.
Rising questions and concerns
- Would Time really benefit from chrono internally? (Probably would have to implement first to find out)
- Does SFML want to keep implicit narrowing conversions and overflows in sf::Time? (Those are edge cases but still exist)
- Would SFML like to introduce asNanoseconds?
- How will compilation time be affected? (Hopefully not much)
I would say that sf::Time unnecessarily duplicates the code of std::chrono and greatly limits the flexibility of working with time. Using time units, conversions and other operations through std::chrono is much more natural and clear. Why should there be a default unit of something called "Int64 m_microseconds;" or "second = float". The user himself should determine the precision he needs for a given operation or what a given time period represents.
Instead of "time.AsSeconds", sf::Clock can be extended to "clock.getElapsedAsSeconds()", but basically it doesn't have much use. Perhaps make more sf::Clock alternatives like stopwatch, pauseable clock and so on would be better idea how improve work with time.
For the stated drawback (even if it's not important at all):
// Instead of
std::cout << "Time: " << duration<float>(t).count() << " second(s)\n";
// You can write
std::cout << "Time: " << duration<float>(t) << "\n";
// Output: Time: 1.001s