Why is there Range and ClosedRange? Why RotatedShape?

[Hacksaw]

I'm trying to understand the philosophy of this.

It seems like there are a lot of paths in swift libraries where a modifier produces a thing which is incompatible with whatever you are doing. For instance ForEach takes a range, but not a ClosedRange. I don't even know why they are different, and I can't at the moment think of a situation where you'd need to know if the Range was closed vs. open.

Equally so, I'm not sure what the benefit of something which accepts a Path, but not a RotatedShape, but the only rotation functions return the latter.

Can anyone elucidate this?

[Ray_Fix]

For Range/ClosedRange an important distinction is that Range can be empty but ClosedRange always contains at least one element. Also, if you want to have a Range of UInt8 and traverse every value, you would need to 0 ..< 256 and 256 doesn't fit in UInt8, which is kind of weird.

If you want to support both range types you can make a generic R that conforms to RangeExpression and then the generic function will cover all of the range types including HalfOpen etc.

[wowbagger (冀卓疌)]

@Hacksaw

I don't even know why they are different

Somewhat relevant (not specifically why Range and ClosedRange are different, but why there are different "range" types):

@beccadax

1. The current design enforces the correctness of iteration.

For instance, suppose you try to do this:

let myRange = ..<3
for i in myRange { ... }

This iteration is impossible to perform because it has no starting value—the last value will be 3, but what will the first value be? Fortunately, the compiler knows that it can’t iterate over a PartialRangeTo , so it rejects this code.

@beccadax

2. The current design makes loops over ranges much faster.

For instance, currently when the compiler sees this:

for i in myRange { ... }

It knows that it can turn that into something like:

var i = myRange.lowerBound
while i < myRange.upperBound {
  ...
  i &+= 1
}

And in general, it actually does—a Swift for i in someRange loop is nearly always as fast as a C for loop.

[Hacksaw]

Okay, that answers one part of my question, and I value that. Thanks!