I agree with this decision, but I would also add the provision that the random number API be designed in such a way that those with special crypto needs can easily extend the existing random number framework to meet their needs. (Specify their own seed, use their own crypto implementation, etc).
I’m sure this is already being considered having read most of the Random Unification email chain, but just thought I’d make sure it was specifically mentioned. I’d hate to leave a group of coders out in the dark (no matter how small that group may be). > On Dec 6, 2017, at 4:16 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > Hi All, > > FYI, the Core Team had a brief discussion about the direction of the random > number API design being discussed. > > The strong opinion of the core team is that such an API should *not* be > designed with an attempt to service people writing crypto code. Such clients > will have requirements that are difficult to predict or that are hard to > provide in general (e.g. “must run in constant time”). These clients are > also relatively few, compared the community of people who benefit from a good > "general use" random number API. > > As such, the core team strongly encourages the random number API design > process to focus on building the best possible "general use" API, without > worrying about the needs of crypto experts. > > Beyond that, the core team did not discuss what the exact shape of the API > should look like: it believes the community should continue hashing it out. > We just wanted to remove one big constraint from that design process. > > Thanks, > > -Chris & Swift Core Team > > > _______________________________________________ > 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
