[swift-evolution] [Proposal] Random Unification
ben_cohen at apple.com
Tue Jan 9 13:01:33 CST 2018
> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution <swift-evolution at 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution