[swift-evolution] Range and ClosedRange

[Dave Abrahams]

on Fri Jan 13 2017, Xiaodi Wu <swift-evolution at swift.org> wrote:

> On Fri, Jan 13, 2017 at 2:05 PM, Max Moiseev via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> FWIW, the common RangeProtocol unifying both Range and ClosedRange existed
>> for a while when the new collection indexing model was being implemented.
>>
>> Here is the commit removing it: https://github.com/apple/
>> swift/pull/2108/commits/8e886a3bdded61e266678704a13edce00a4a8867
>>
>> Max
>>
>
> From the commit: "The RangeProtocol was a very weak and fragile abstraction
> because it didn't specify the interpretation of the endpoints.  To write a
> non-trivial algorithm, one usually needed to consult that information."
>
> As I argued (perhaps inarticulately) above, I think it may be worthwhile
> revisiting the abstraction once conditional conformances become possible.
> We can say more about the relationship between the endpoints of half-open
> and closed _countable_ ranges than we can of uncountable ones.

Yes, here's my plan (pending approval by this list of course):

1. Get rid of Countable[Closed]Range and use conditional conformance
   (when we get it) to make [Closed]Range conform to Collection when
   appropriate.
  
   1a. typealias CountableRange<T> where ... = Range<T> for backward
   compatibility.  Similarly for CountableClosedRange.
   
2. Implement
   https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md
   This is a good proposal, badly formatted (sorry!)  It includes a
   protocol RangeExpression, to which the ranges conform.  Making this
   work really cleanly depends on having generic subscripts.

>> On Jan 12, 2017, at 12: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
>

-- 
-Dave