[swift-evolution] [Proposal] Random Unification

[Brent Royal-Gordon]

On Oct 11, 2017, at 10:02 AM, Kevin Nattinger via swift-evolution <swift-evolution at swift.org> wrote:
> 
> IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array (RandomAccessSequence?), they should just be for convenience and with a sane default RNG*, and users that need more should just use methods on the RNGs directly.

No—that means code which uses these extremely convenient and attractive APIs can never be testable and that there's no obvious way to go from "use the default RNG" to "use this specific RNG".

Methods which use an RNG should take that RNG as a parameter—a parameter with a default value of "the default RNG":

	init(randomIn range: CountableRange<Self>, from randomizer: Randomizer = DefaultRandomizer.shared) {
		…
	}

This properly separates concerns between the Randomizer (which knows how to return random data) and the type (which knows how to construct itself from random data). It also makes it easy to use a randomized API you already knew about with a RandomSource, and it creates a convention that users can apply to their own designs for how to write testable and customizable randomized code. We might even add a local refactoring which automatically adds a Randomizer parameter to the function and passes it to randomized calls within the body.

Don't add a global setter—you don't know what it might affect. Don't add a bunch of calls constructing arbitrary types to the Randomizer (or whatever it's called) protocol. Do it with dependency injection: pass the Randomizer as a parameter.

-- 
Brent Royal-Gordon
Sent from my iPhone