on Fri Jan 13 2017, Xiaodi Wu <[email protected]> wrote: > On Fri, Jan 13, 2017 at 2:05 PM, Max Moiseev via swift-evolution < > [email protected]> 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 < >> [email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
