I'd like SFML to keep its own clock wrapper because I use the C binding of SFMLBindings should not interfere in the design choices for the core libraries. If feature xxx is standard in C++ but not in yyy language, then SFML should not be concerned about it ;)
sf::Time looks much better than the standard equivalent (either verbose templates everywhere, or std::chrono::nanoseconds which looks confusing). So I'd keep it. With additional conversions to and from std::chrono::duration, if possible.
By the way, is std::chrono::duration<float> a number of seconds?Yes, the default ratio for time duration is one, which is expressed in seconds. Also relevant for the curious among us: http://en.cppreference.com/w/cpp/chrono/treat_as_floating_point
We could simply use an alias in the sf namespace to represent time durationI can imagine a few drawbacks:
What if sf::Time just stored time in std::chrono::nanoseconds and had all the same functions like asSeconds(), asMilliseconds() and just used duration_cast in implementations?That was the implicit plan :)
We may also add some user-defined literals like "s", "ms" and then we'd be able to write
sf::Time may also have implicit constructors which accept std::chrono::nanoseconds, std::chrono::milliseconds, std::chrono::seconds so that conversions from standard library things to sf::Time are possibleImplicit constructors already allow to write "music.setPlayingOffset(500ms), no need to define our own user-literal suffixes.
Well, if there still will be sf::Time in SFML3 it would be quite important to provide method like asStandardDuration() (in addition to asSeconds() etc.) so it wouldn't be a problem to get it work with stuff like std::this_thread::sleep_for()It was already said at least twice ;)
I also read trough it twice and still didn't notice that. ;-; Well, that's my opinion, at least you know what folks think.QuoteWell, if there still will be sf::Time in SFML3 it would be quite important to provide method like asStandardDuration() (in addition to asSeconds() etc.) so it wouldn't be a problem to get it work with stuff like std::this_thread::sleep_for()It was already said at least twice ;)