The specification, as far as I'm aware, gives no guarantees at all about the algorithm used. Why not just specify a good algorithm instead of adding a new function?
They added more than a single new function. Personally, I like what was added. For what it's worth, I generally don't need to consult the documentation for the new random facilities (for a definition of "new" that includes "four years old"), but I do need to consult the docs for the stuff in <chrono>.
> The specification, as far as I'm aware, gives no guarantees at all about the algorithm used.
You are right about that. And, in fact, the few guarantees the standard has are weak enough that Microsoft ships a standards compliant implementation that is famously limited.
> std::rand has global state. Specifying the algorithm doesn't fix that.
Adding other functions also doesn't fix std:rand. People use std::rand. They will continue to use std::rand, unless it's removed. And even then they'll keep using it, because implementations will add it back in for compatibility.
There's already a simple, half baked, crude random number generator. It's possible to fix it so that it provides at least acceptable randomness, and isn't complete junk. Doing this breaks nothing.
Why add another similar function with similar API issues?
What is this "similar function" with "similar API issues"?
C++11's random utilities and O'Neill's randutils aren't similar to std::rand at all. They're totally different beasts from std::rand.
Making std::rand a decent RNG would probably make the world a better place. I'm not disagreeing with that. But even if std::rand used a decent algorithm, it's still a suboptimal API.
The specification, as far as I'm aware, gives no guarantees at all about the algorithm used. Why not just specify a good algorithm instead of adding a new function?