I like the earlier version we were talking about with both .random(in: ClosedRange<>) and .random(in:ClosedRange<>, using: RandomSource)
Thanks, Jon > On Oct 12, 2017, at 10:30 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > > On Oct 11, 2017, at 10:02 AM, Kevin Nattinger via swift-evolution > <[email protected]> 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 > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
