[swift-evolution] Range and ClosedRange

[Xiaodi Wu]

I agree that there are use cases where the distinction between ClosedRange
and Range is less ergonomic than perhaps possible. However, I would be very
much against rolling back the improved correctness, but as has been
suggested by a previous comment on the swift-users lists, a protocol would
not be out of place. By current Swift conventions, and given our goal of as
much source compatibility as possible (i.e. not renaming `Range`), such a
protocol would be named `RangeProtocol`.

At the moment, we actually have four range types: Range, CountableRange,
ClosedRange, CountableClosedRange. Once conditional conformances fall into
place, the Countable versions can go away. There are useful algorithms that
can ignore the distinction between an open range and a closed range when
the bounds are countable (e.g. Int) that do _not_ make sense when the
bounds are not countable (e.g. Float). This comes down to the fact that
`0...(2 as Int)` is in many ways another way of expressing `0..<(3 as Int)`
but `0...(2 as Float)` is very much not the same thing as `0..<(3 as
Float)`. Therefore, IMO it'd be wisest to hold off on designing a
`RangeProtocol` until the requisite generics features are implemented, so
that the final design can take advantage of such features for a maximally
ergonomic but still correct design.


On Thu, Jan 12, 2017 at 3:44 PM, Adriano Ferreira via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi David,
>
> There were a few instances where this topic or similar came up at the Swift
> Evolution List
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160905/026923.html>
>  and Swift Users List
> <https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20161010/003631.html>
> .
>
> There’s even this interesting proposal
> <https://github.com/luish/swift-evolution/blob/f99e325484a5b19ce4bab8eda18f284e4e250e7b/proposals/nnnn-more-lenient-collections-subscripts.md> that
> dwells with it while providing more lenient subscripts to collections.
>
> BTW, I agree with you, having the range type split is somewhat confusing,
> specially for those new to the language.
>
> Best,
>
> —A
>
> On Jan 12, 2017, at 3:11 PM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello,
>
> Since the release of Swift 3, I’ve seen quite a few people (me included)
> experience a lot of friction with the new types for representing ranges.
> I’ve seen people confused when writing an API that takes a Range as
> argument but then can’t pass in a ClosedRange. Sometimes this can be fixed
> because the API should be written against a more general protocol, but
> sometimes that’s not the case.
>
> Those new types definitely seem to cause more problems than they fixed
> (the Int.max problem). Has the Standard Library team put any thought into
> this?
>
> Regards,
> David.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170112/a0ca8f2c/attachment.html>