> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution > <swift-evolution@swift.org> wrote: > > - Why bother supporting non-closed Ranges at all? If you only allow closed > ranges, then you can’t end up with an empty range. The only difference in > behavior I can think of is on floating point, but I can’t think of a use-case > where excluding the supremum is actually useful in any real world way. >
Ranges are the currency type, whereas closed ranges aren’t. We should try to avoid any solution that goes against this pattern. People are going to have a Range, and having to convert it into a ClosedRange just to get a random number from it is confusing. The argument goes that you want to avoid traps, therefore forbid half-open range because it can be empty and might trap, whereas closed ranges doesn’t. Therefore, let’s only have closed ranges. Type safety ftw. In practice, I don’t think this is justified. Realistically, you can divide uses into two cases, literals and runtime-generated ranges. Literals are obviously empty by inspection. It’s hard to do this by accident and any kind of coverage testing of (0..<0).random() will immediately trap. So probably a non-issue. If you’re generating ranges at runtime from variables, you have another risk of traps that applies just as much to closed ranges: inversion. i.e.: x = 5 y = 4 x...y // boom, can't form Range with upperBound < lowerBound This is easily done. Nate’s example playground even had a possible case! // better hope items always has at least 3 elements... let countForSale = (3...items.count).random() Given this is already an issue, the additional risk of trapping on empty half-open ranges seems modest and acceptable to me, compared to the alternative of encouraging constant banging of the result from .random() on ranges.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
