[swift-evolution] [Proposal] Random Unification

[Dave DeLong]

A massive +1 for this approach too.

As a “least competent engineer” when it comes to random numbers, I’d really appreciate having safeguards in place to keep me from inadvertently shooting myself in the foot.

Dave

> On Oct 11, 2017, at 11:21 AM, Cory Benfield via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I strongly recommend building the padded room.
> 
> Average to good engineers (which I assume is intended to be a proxy for “engineers who know about CSPRNGs and have considered their personal threat model”) know enough to work out what kind of RNG they have available and to use the one most appropriate to their use-case. That means if the default is “slow and cryptographically-secure” but they need “fast and not cryptographically-secure", they’ll know enough to opt-out. If the default is “fast and not cryptographically-secure”, they’ll also know enough not to opt-out. In all cases the cost to this engineer of using the default is 20 minutes (the time required to find out what the default is), and the cost of using not-the-default is 20 minutes and a few lines of code. Marginal.
> 
> The hypothetical least competent engineer, by definition, does not know enough to check what RNG they have available. If the default is “slow”, they’ll get “slow”: in the worst case, their code will be slower than it needs to be because they could have used “fast” instead. If the default is “fast”, they’ll get “fast”: in the worst case, their code will be vulnerable to attack. This user will never swap away from the default, so the question is which failure mode is preferable. I’d say it seems pretty obvious that “my program is slow” is a better failure mode than “my program is vulnerable to data exfiltration”.
> 
> It’s completely worth it, IMO, to cost engineers that know what they’re doing with an RNG a small amount of time to save us from the errors made by engineers who don’t know. But it’s a false dichotomy to say that not having a padded room is only a danger to the engineer writing the program: as Equifax has demonstrated, we’re all on the hook for their work.
> 
>> On 11 Oct 2017, at 10:02, 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.
>> 
>> *: I don't think the default necessarily needs to be a CSRNG; if there's a fast one, fine. Are we building a padded room for the least competent engineer or a tool for the average to good engineer to use efficiently?
>> 
>>> On Oct 11, 2017, at 9:08 AM, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I’m a bit late to the party on this one, but has anybody considered the fact that you need a way for the user of the interface to override the default random number source?
>>> 
>>> For example, some applications require a cryptographically secure source, others might eschew perfect entropy for speed. Still others might want repeatability e.g. Minecraft lets you enter a seed when it does the World generation so you can go back and play the same World again and again. For unit testing, you might want to replace the random number generator with a sequence of hard coded values so you can exactly control the code path that the test takes.
>>> 
>>> So if you have a protocol that describes an API for generating random numbers called RNG, the extension on Int would look something like
>>> 
>>> extension Int {
>>> init(randomInRange: Countable{Closed}Range<Int>, rng: RNG = /* a CS random number generator */)
>>> }
>>> 
>>>> On 7 Oct 2017, at 04:24, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>>> On Oct 5, 2017, at 10:58 AM, Nate Cook via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> The edge case is really the same (empty ranges), it’s about what we do with the edge case. If we include the methods on integer types, usage will look like this:
>>>>> 
>>>>>  let x = Int.random(in: 0..<5)     // 3
>>>>>  let y = Int.random(in: 0..<0)     // runtime error
>>>>> 
>>>>> If we only have the collection methods, usage will look like this:
>>>>> 
>>>>>  let x = (0..<5).random()!         // 3
>>>>>  let y = (0..<0).random()!         // runtime error
>>>> 
>>>> These aren’t the forms I was suggesting, what I meant was:
>>>> 
>>>> extension Int {
>>>> init(randomInRange: Countable{Closed}Range<Int>)
>>>> }
>>>> 
>>>> which gives:
>>>> 	let x = Int(randomInRange: 0..<5)
>>>> 
>>>> The point of this is that you’re producing an Int (or whatever type).  Regardless of whether the initializer is failable or not, this is the preferred way of creating a new value with some property: it is an initializer with a label.
>>>> 
>>>> -Chris
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution