Rather 0 ..< 0 my bad. I think if we include closedcountable, then there needs to be support for countable, but there are edge cases where users can input invalid ranges for countable.
Enviado desde mi iPhone El oct. 5, 2017, a la(s) 12:22, Alejandro Alonso via swift-evolution <[email protected]<mailto:[email protected]>> escribió: I agree with Ben here because users can still enter an invalid range with the static function. I.E. Int.random(in: 0 ... 0). I would really prefer excluding these static functions from numeric types. - Alejandro El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution <[email protected]<mailto:[email protected]>> escribió: On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution <[email protected]<mailto:[email protected]>> wrote: On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution <[email protected]<mailto:[email protected]>> wrote: ``` extension Int { static func random(in range: Countable{Closed}Range<Int>) -> Int } Nice. Should these be initializers like: extension Int { init(randomIn: Countable{Closed}Range<Int>) } I don’t see much of a case for making it it random(in: SpecificCollection) instead of genericCollection.random(). I see a couple points in favor of these static methods (or initializers) on the numeric types: 1) The collection method will need to return an optional to match the semantics of existing methods (like min()). If this is the only method available, every time someone needs a random value in the range 1...10, they’ll need to unwrap the result (with either force unwrapping, which people will complain about, or some kind of conditional binding, which is its own problem). Even if the semantics are the same (trapping on an empty range), the user experience of using a non-optional method will be better. 2) Floating-point ranges won’t get the collection method, so either we’ll have inconsistent APIs (random FP value is non-optional, random integer is optional) or we’ll make the FP API optional just to match. Both of those seem bad. One possible reason is if you exclude half-open ranges, only having CountableClosedRange, then you don’t have to account for the possibility of an empty collection (via an optional or a trap) because they cannot be empty. But closed ranges aren’t the currency type – half-open ranges are. So it’d hit usability if you have to convert from one to t'other often. Other possibility is discovery. But given the common use case is “random element from collection”, I don’t expect this to be an issue as it will quickly become common knowledge that this feature is available. Agreed here—I don’t think discovery is really an issue between the two kinds. However, I don’t think the overlap in features (two ways to generate random integers) are a problem, especially as we’d have better alignment between integer and floating-point methods. Nate _______________________________________________ swift-evolution mailing list [email protected]<mailto:[email protected]> https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected]<mailto:[email protected]> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
