> On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > If trapping is OK, then surely returning Optional is superior; any user who > is OK with trapping can make that decision for themselves by writing > `random()!`. Everyone else can then see clearly that trapping is a > possibility, which is important.
It’s important not to underestimate both the extent to which using `!` scares people, _and_ the extent to which beginners use it inappropriately. Both of these mean that it’s very important the standard library not include anything that makes force-unwrapping a common/routine operation (looking at you, UnsafeBufferPointer.baseAddress). Given that arc4random, the recommended source of random numbers on Darwin, is always successful, requiring a force-unwrap when the user is using the default source doesn’t seem like the right move. > On Wed, Oct 4, 2017 at 11:09 David Waite <da...@alkaline-solutions.com > <mailto:da...@alkaline-solutions.com>> wrote: > >> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> I agree with Felix’s concern, which is why I brought up the question, but >> ultimately the issue is unavoidable. It’s not down to global instance or >> not. If your source of random numbers is unseedable and may mix in >> additional entropy at any time, then it may fail at any time because when a >> hardware restart might happen may be transparent to the process. The user >> must know about this or else we are laying a trap (pun intended). > > I'm of the mindset (which might be controversial) that we should attempt to > expose legacy and cryptographically secure random number generators, even a > mixed algorithmic/entropy source like /dev/urandom, but that we should not > expose /dev/random at all. If someone is trying to use /dev/random > legitimately (such as to generate one-time-pads) they will have to take into > account that systems like linux still use algorithmic entropy to drive > /dev/random. If someone really has this sort of use case, they have exceeded > the bounds of the system randomness protocol. > > Without /dev/random support as a requirement, the only failure cases I know > of are reading too much random data in one operation (which could be solved > by repeated calls) or calling before sufficient entropy has been set up in > /dev/urandom (such as in a system startup process). I'd be fine with the > second one being a special case, and such systems needing to know use of the > /dev/urandom -backed generator before randomness has been set up will trap or > return predictable information on certain platforms. > > -DW > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
