[swift-evolution] Range and ClosedRange

[Sean Heber]

I would very much like to know what the status is of conditional conformances and if there’s a timeline for them or they are underway or whatnot. My unscientific gut check suggests something like 50% of recent proposals or rough ideas have been impaired by their absence. :P

l8r
Sean


> On Jan 12, 2017, at 4:03 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 and Swift Users List.
> 
> There’s even this interesting proposal 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
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution