proposal: math/rand: add Reader variable

[dsnet]

The crypto/rand has both a Read function and a Reader object for passing in as an io.Reader. The math/rand package only has a Read function and no Reader object.

Should we add a Reader to math/rand to make it consistent with crypto/rand?

[bradfitz]

I thought this was a dup, but I was thinking of #8330 which went most of the way, but not all the way.

I still think there was an open bug or thread about this, but I don't remember the outcome.

[dsnet]

When #8330 was first implemented, I noticed that it didn't include an implementation for a Reader object. Back then, I didn't speak up because it's not a big deal.

I think it'd be nice, but everytime I really wanted to use random Reader, I just do rand.New(rand.NewSource(0)) and move on in life.

[ldemailly]

It would be nice, in particular to provide a concurrent safe version of rand.New(rand.NewSource(0)) that can be used for instance for github.com/google/uuid.SetRand() for fast concurrent uuid generation

[rsc]

Bumping over to proposal process. I think we should not do this. There are very few reasons to use a pseudo-random byte stream, and I worry about 'rand.Reader' completing to math/rand.Reader instead of crypto/rand.Reader. In general I wish we'd done a better job of keeping math/rand and crypto/rand's APIs completely disjoint, and in particular I regret adding math/rand.Read in the first place. I don't think we should exacerbate the problem by adding math/rand.Reader as well.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group