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. On Wed, Oct 4, 2017 at 11:09 David Waite <[email protected]> wrote:
> > On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution < > [email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
