It is general goodness if generality for crypto use cases somehow falls out of the design. However, the design for general use shouldn’t suffer because of that goal.
-Chris > On Dec 6, 2017, at 3:47 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > So, my read of the decision is that when the core teams says the API should > be designed “without worrying about the needs of crypto experts,” they mean > exactly that we should stop worrying about how easy or hard it is to extend > for those users. > > On Wed, Dec 6, 2017 at 18:34 Jacob Williams via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > 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 <mailto: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 <mailto:swift-evolution@swift.org> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution