The bell has tolled for rand()

> hard to imagine a case where a 623-dimansionally equidistributed PRNG could fail

Well, there is the generalization and improvement of MT19937 in form of the WELL generators. They go beyond that, so there probably are cases where it's needed.

> PRNGs could become obsolete but "truly random" will always mean the same

I'd argue that far fewer people need truly random than those who just need a dice roll.

There are those who work on crypto. They won't need anything in the C++ stdlib because there are libraries specifically for that. They also provide much more that is needed for programs utilizing cryptographic primitives. This group should know what they're doing and choosing, and if not should have no business writing such software. And they won't even accidentally pick MT.

There are those who do numerical simulations. They neither need or can use a "truly-random" generator because submitting a paper with the words "to reproduce our results, grab the following 2 TiB file of random bits ..." is probably frowned-upon. Reproducability of a sequence is a feature, and a good one. Heck, quasi-random algorithms also have their place. In any case, you shouldn't do simulations with just a single PRNG either to rule out interactions between intricacies of your model/simulator and the PRNG. So people in this group are likely to use a framework or library that caters to their needs, too, which includes several different PRNGs (even obsolete ones for checking older results), distributions, special data structures needed for certain kinds of simulations (e.g. event queues), etc. This group also should know what they're doing and why, otherwise they shouldn't publish research at all.

And then there is everyone else who just needs a random number every now and then. Maybe for shuffling a playlist, maybe for rolling a die. Having easy access to a PRNG that works well for a large number of use cases (they wouldn't have any idea what to choose anyway) is a major benefit to this group. They don't care about (or notice) the difference between pseudo-random and truly random (even though the latter sounds more impressive and the former somehow not random enough, even though anything that doesn't look random in the former case is often bad seeding, e.g. in a loop). They just want something to work. MT19937 is a very safe choice for this group, and as an added benefit, it's much better and often faster than LCGs.

Yes, that was my intent: the manual entry used the term "bad spectral characteristics" condescendingly, instead of actually admitting that rand was a terrible mistake and nobody should ever use it. The effort the manual writer put into rationalizing the bug would have been better put into fixing it.

I looked up "mansplaining" on the urban dictionary while writing that, and was disgusted to see that it was full of sexist definitions written by obviously butt-hurt men's rights advocates, literally blaming angry misandrist pseudo-intellectual ugly insecure radical fat women for using it as a get-out-of-jail-free card against daring opinionated oppressed men. http://www.urbandictionary.com/define.php?term=mansplaining

So it's possible the downvotes came from red pill poppers reflexively reacting to my use of the word "mansplaining", and if so, I suffer those fools gladly, and hope to earn their downvotes again. http://www.salon.com/2014/07/01/feminism_is_a_sexual_strateg...

Here's a Unix manual entry that I wrote, which made it into Solaris and SVR4, whose BUGS section is now obsolete thanks to technological advances based on high quality pseudo random number generators, like https and PayPal: https://stuff.mit.edu/afs/net/system/sun4c_41/rsp.01/usr/ope...

It's good that they did that, as a safety net for old code, but none of the standards which define rand() guarantee or even suggest uniform randomness, so the bell has still certainly tolled.

That's part of exactly what makes the problems with rand() so intractable. Whether a program performs as specified is an arbitrary function of real world state.

> Picking one is not without compromises: Do you want your PRNG fast? Or do you want it cryptographically secure?

Many library functions involve tradeoffs. Do you want your malloc() fast? Or do you want it to minimize memory usage? Do you want your sorting function to be fast in the average case or be without pathological edge cases? A PRNG is no way unique in this respect.

The standard library is ultimately a tool like any other; it should contain things that are useful. Of course there are compromises involved in any particular choice of PRNG, but that doesn't mean not including any is a better choice.

My view is that a lot more things should be rigidly specified by the standards. The days of radically varying CPU architectures and radically different OSes are gone; these days underspecification mostly serves to trip programmers up. Standardizing the memory model was a huge step forward, and it's time for C++ to go further in that direction, time to start defining what was previously undefined or implementation-defined behaviour.