Open Radar

 
Summary:
When you have a function:

func f(r: Range<Int>) { ... }

and you call it with f(3..6) then the Range's endIndex is 6. When you call it when f(3...6), then Range's endIndex is 7. That might make sense for integers (the function can always consider endIndex to be exclusive), but not for floats.

func g(r: Range<Float>) { ... }

Calling g(3.0 .. 6.0) creates an endIndex of 6.0; calling g(3.0 ... 6.0) creates an endIndex of 7.0. There is no way for g() to see whether the endIndex is supposed to be inclusive or exclusive. It cannot treat endIndex as always being exclusive by subtracting 1.0 from it.

For example if g() is supposed to return a random number in the range, then g(3.0 .. 6.0) should return a number between 3.0 and 5.99999 and g(3.0 ... 6.0) should return a number between 3.0 and 6.0. If we were to always subtract 1.0 from endIndex then g(3.0 .. 6.0) returns a number between 3.0 and 5.0, not 5.9999.

Steps to Reproduce:
Write a function that takes a Range<Float> or Range<Double>. It is impossible for the function to determine whether the upper bound of the range is inclusive or exclusive.

Expected Results:
The Range<> struct should have a field that indicates whether the upper bound is inclusive or exclusive.

Actual Results:
For floating-point ranges there is no way to tell how the upper bound should be treated.