Features like this make me think that C++ is designed by people who think that perfection is reached when there is nothing more to add. As a C developer, I side with Antoine de Saint Exupéry.
I don't think C developers should be sitting on a high horse on this one.
C represents a pretty good example of the problem. Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution, so any correct program completely bypasses that infrastructure and/or has a ton of additional code/complexity layered on top of it.
That open source basically festered until the C++11 <random> proposal was accepted. The chief proponents of that proposal were, of course, those with the most sophisticated needs & understanding for random functions, and the proposal reflects that. So, the problems with that proposal are arguably a consequence of the flaws in the original C standard.
What remains to be done is to harmonize that proposal with something that makes sense to less sophisticated users, who nonetheless have reached the point where their appreciate the problems with C's random functions.
Right, and that function is a mistake in the C standard. It should have been omitted entirely.
Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.
See, for example, crypto before NaCl came around.
(NB: I'm not defending either this C++ standard or random(3).)
Sure... but what happens if you do specify that implementations should be built-in is that a diverse, bewildering ecosystem of broken implementations get built in, and so people who know what they're doing end up eschewing the built-in implementations in favour of shipping with an implementation which they know works. And ultimately you have a standard function which everybody provides for compatibility purposes, but which nobody should ever use. See, for example, random(3).
Functionality should be added to standards when we can be confident that every implementation in the next 100 years will get it right, and no sooner.
Although, I've never actually seen it used in the wild.
So, it leads me to guess there's two ways the the C++ situation would've been made unnecessary:
1. Leave it out of C itself but pro's build and maintain a de facto standard in form of a library as easy to use as random and widely available. Can even be OS random facilities cleanly wrapped.
2. Put a good one in C standard. Becomes the standard de facto and officially.
Preconditions didn't exist or convenience prevailed. So, now there's a new attempt at dealing with the mess. That's my guess as a person looking on from the outside rather than a user of all these tools. Just to be clear on that part.
However, eventually you need to provide something that works. There is some value in having a portable way to generate random numbers. I can't think of a language that doesn't define one, and I don't think that is by accident.
Man, autocorrect killed me there. That should be "That open sore".
So yeah, not exactly addressing the matter.
Of course, that whole arc4* library doesn't have the same challenges as a language standard, which is where a lot of the challenge here comes from.
(I don't write code where e.g. std::poisson_distribution would be useful, so I don't feel I have the background to have an opinion on that part of the proposal.)
Overflow is something that the programmer always has to keep in mind, unfortunately.
The proposal doesn't really care much about distributions. It's intended for people who don't care about random distributions.
Although we have different concerns, it's clear that a lot of thought has been put into the proposal, and it seems to achieve its/your goals pretty well. Don't let my concerns put you off.
To satisfy the two camps though (low level control vs "give me some sane default or package up common combinations") someone just writes the higher level API on top.
Or maybe your idea of "just the right amount of stuff" is different from someone else's idea of that, and we could be thankful that the world is able to accommodate more than one opinion on this by providing us with multiple programming languages we can use according to our needs and preferences.
C with nothing left to take away is portable assembly.