proposal: x/exp/rand: add NewLockedSource

[krancour]

This related issue makes a case for math/rand exporting some implementation of Source that is concurrency safe.

Pursuant to that, this change exports LockedSource from golang.org/x/exp/rand. That seems like a nice start, however, with LockedSource's attributes still being unexported and with there being no constructor-like function for instantiating a new LockedSource, there remains no practical way to initialize variables of that type.

I want to propose the addition of a new package-level function NewLockedSource(seed uint64) Source in golang.org/x/exp/rand.

I'm happy to PR this myself if there's some consensus that this is a reasonable change.

[ianlancetaylor]

CC @robpike

[robpike]

This seems reasonable, but I'd like to hold off changing exp/rand's API too much until the various proposals about the future of the math/rand package are resolved.

[krancour]

This seems reasonable, but I'd like to hold off changing exp/rand's API too much until the various proposals about the future of the math/rand package are resolved.

@robpike, I'd like to start contributing. Can you help me understand the above? It seems to me that exp/rand like many other exp/... packages is an experiment that occurs in parallel to sorting out the future of some existing package. I guess what I don't understand is why it wasn't premature for you to create exp/rand while the future of math/rand gets hammered out, but it's premature to add one simple function to it.

EDIT: I'm worried the above sounds much more confrontational than intended. I'm genuinely trying to understand the process here so I can help.

[ianlancetaylor]

x/exp/rand was created as a possible replacement for math/rand for Go 2. As such, x/exp/rand is intended to provide the same API as math/rand. Changing the API of x/exp/rand complicates the decision of whether to use it as a replacement for math/rand.

[krancour]

@ianlancetaylor that's a great explanation and it makes a lot of sense. Thank you.

I'll point out, however, that there are already changes to the API in exp/rand, such as LockedSource now being exported when it previously was not. Exporting it, however, has not resulted in any meaningful improvement because you still cannot initialize one. All I am proposing here is to correct a mistake. I'm not sure how that would complicate the future direction of exp/rand or math/rand.

[robpike]

Makes sense, but my point about holding off still holds. The interface and some internals for math/rand have also changed lately, and I would like to bring exp/rand into sync before moving on with exp/rand. I'll plan to do that soon.

[krancour]

Thanks @robpike. Is there anything I can do then to help you sync these packages and solidify their future direction?

[robpike]

It is part of the point of exp/rand to not have to lock the source, by making it cheap enough to have lots of them and high enough quality not to worry about correlations between sources. Putting a NewLockedSource API in the package goes against the idea for the package's model.

[krancour]

@robpike I've understood that that was a goal. I see how that makes it feasible to give a very large number of goroutines their own Source, thus eliminating any contention. However, I think there is a very broad range of patterns not supported by that.

Consider, for instance, a discrete function such as the one below. This is already concurrency safe (but is at risk of some other code changing the seed) and is utilized concurrently by many, many goroutines.

package generator

const (
        lowerAlphaChars  = "abcdefghijklmnopqrstuvwxyz"
	upperAlphaChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
	numberChars       = "0123456789"
	passwordLength  = 16
	passwordChars    = lowerAlphaChars + upperAlphaChars + numberChars
)

// NewPassword generates a strong, random password
func NewPassword() string {
	b := make([]byte, passwordLength)
	// Passwords need to include at least one character from each of the three
	// groups. To ensure that, we'll fill each of the first three []byte elements
	// with a random character from a specific group.
	b[0] = lowerAlphaChars[rand.Intn(len(lowerAlphaChars))]
	b[1] = upperAlphaChars[rand.Intn(len(upperAlphaChars))]
	b[2] = numberChars[rand.Intn(len(numberChars))]
	// The remainder of the characters can be completely random and drawn from
	// all three character groups.
	for i := 3; i < passwordLength; i++ {
		b[i] = passwordChars[rand.Intn(len(passwordChars))]
	}
	// For good measure, shuffle the elements of the entire []byte so that
	// the 0 character isn't predicatably lowercase, etc...
	for i := range b {
		j := rand.Intn(len(b))
		b[i], b[j] = b[j], b[i]
	}
	return string(b)
}

Re-writing this to utilize the model you're proposing in exp/rand gives me two unpalatable choices for moving past the risk of some other code altering the seed.

1. I allocate a new Source every time this function is called-- which seems wasteful.
2. I pollute the function signature by requiring every caller to pass in the Source belonging to their goroutine.

Neither of these is a good option and afaict, they're the only two options that the model you're proposing would give me.