Such an operator would be meaningful if it didn't just forward the call to asMicroseconds(), but output the value in a way that is recognizable as time. For example:
32s 765ms 320us
I feel it's like with other requests that it doesn't really add anything that useful, but rather forces the user to one way. Everyone can already write a one liner to format the time in the way they want, thus is the gain bigger than the possible confusing among the users (e.g. "How do I make cout << myTime only display seconds?" etc.).
But to do this, people would have to agree on a common format. So far, SFML doesn't overload the operator<< for I/O streams anywhere else (vectors, rects, colors, ...) -- why exactly time?
That's the other thing, once we do it for one thing, we'll have to do it for the rest as well. It's basically just a functionality that's there for the lazy developers, because very rarely is one going to use an << for production code.
Btw., I was actually surprised a bit when finding out SFML is having a kind of very limited log-library hidden inside with the err stream. Adding a time to it may actually be a nice addition there, too. And if that would get implemented there are dozens other possible features for the log-library that may be nice, but I feel that distracts a bit from the M in SFML and may be something for a dedicated log-library.
It's not a log-library and it should never develop into that. The reason
sf::err exists is to give all the power to the user. If I want SFML's error not to appear on
std::err it wouldn't have been possible to do so without
sf::err (disregarding the idea of a global setting). With
sf::err one can easily redirect the output. Forcing a timestamp would be quite bad as well. What if I have my own logger and want the timestamp to be format different or non-existing at all?
And finally it's again really easy to write your own logger and output your own timestamp without limiting anyone.
As a side note, such API changes would probably only be added for SFML 3 and if all goes well, we'll have exceptions there, so it's quite possible that
sf::err will then disappear.
![Wink ;)](https://www.sfml-dev.org/forums/Smileys/default/wink.gif)