Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: math/rand: rework for Go 2 #26263
I propose that math/rand be overhauled for Go 2.
Rob Pike has proposed some aspects of a better math/rand for Go 2 in #21835. This proposal is intended to complement and extend that proposal. It may make sense to merge them, although their scopes are (intentionally) mostly disjoint.
This proposal is not fully polished, but I have been sitting on it for months. It past time to post it. I look forward to a vigorous discussion.
A re-think of math/rand should include:
This proposal will discuss all of these, in turn, and then knit the results of those discussions into a single proposal.
Please note that I am not a subject matter expert. Input from experts (and non-experts) is welcomed.
I begin with compatibility guarantees, as decisions here impact almost every aspect of the rest of the proposal.
The Go 1 Compatibility Guarantee left some ambiguity about when the values produced math/rand should remain stable. For the life of Go 1, math/rand has remained extremely stable. To my knowledge, only a single change to the value stream has ever occurred (#16124). Many opportunities to break stream stability have been declined. There's a fair amount of discussion in #8013; it is recommended background reading. More discussion can also be found in: #13215, #14416, #11871, #8731, #12290, #6721.
There are plausible use cases in which stability matters, such as test cases discovered using testing/quick. There are also plausible use cases in which stability is irrelevant, such as adding jitter to exponential backoff code. Stability adds significant brittleness; there's not much more to math/rand beyond the exact value steam.
I propose a compromise.
Top-level convenience functions, like
This means that any given
This also means that the
Taken together, it is likely that the top level convenience functions will diverge over time from the stable
That seems more of a cmd/go question than a math/rand question.
I can see the argument for disabling caching for tests in which a random element is a key input to the test, as with testing/quick (#26276). But marking a test as not cacheable because any math/rand function has been called seems like a bad idea, since they may be called as an unrelated side-effect of what you’re actually testing, e.g. by some init function in some dependency. I’m not sure how to draw the line, but I think it’s unlikely that the line is “uses math/rand”.
In any case, I think this question is probably orthogonal to this proposal.