[swift-evolution] Range and ClosedRange

[David Hart]

I read this great post. But it shows an example where the problem is circumvented because the algorithm can work on a more general protocol. But the problem still persists for algorithms which make sense for any countable range (open and closed).

> On 13 Jan 2017, at 02:57, Adriano Ferreira <adriano.ferreira at me.com> wrote:
> 
> Hi Dave,
> 
> I’m not arguing about correctness cause I understand the reasoning behind it, but about the abstraction itself.
> 
> I believe a simplified interface would be more fun to use and less confusing. This post from Ole Begemann talks a little bit about this interesting idea.
> 
> Best,
> 
> —A
> 
>>> On Jan 12, 2017, at 5:55 PM, David Sweeris <davesweeris at mac.com> wrote:
>>> 
>>> 
>>> On Jan 12, 2017, at 15:44, Adriano Ferreira via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> BTW, I agree with you, having the range type split is somewhat confusing, specially for those new to the language.
>> 
>> Do you mean that you think having two types is confusing, or that the way we currently split them is confusing?
>> 
>> If it's the former, then I disagree... IIRC, open vs closed ranges is covered in high school math, and IMHO it's not too hard to see the usefulness of both "0..<5" and "1...5".
>> 
>> If it's the latter, I think it's only confusing because, well, partly because we only implement half the kinds of ranges ("lower" is always closed, but that's another thread), but mostly because we don't have generic protocols yet. If we could write
>>    protocol Range<T> where T : WhateverTheCurrentConstraintsAre {
>>        var lower: T {get}
>>        var upper: T {get}
>>    }
>> Then we could define the concrete types as
>>    struct CCRange<T>: Range<T> {...}
>>    struct CORange<T>: Range<T> {...}
>>    struct OCRange<T>: Range<T> {...}
>>    struct OORange<T>: Range<T> {...}
>> (Or spell it out, "ClosedClosedRange", if you don't like the abbreviations.) Then in code, since `Range` doesn't have any "Self or associated type requirements", you can make just make it the type of a variable. In fact, if I'm not mistaken, the "..<" and "..." operators could even return a `Range` instead of the relevant concrete type
>>    var x = 0..<5 // "..<" returns `CORange as Range`
>>    x = 0...4 // "..." returns `CCRange as Range`, which is fine because x's type is `Range`, not `HalfOpenRange` (or whatever it's called now)
>> We'd get full polymorphism between all the types of range without losing the value semantics we want, and the current method of overloading functions is still available if you need the speed of static dispatch.
>> 
>> - Dave Sweeris 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170113/ed3765f4/attachment-0001.html>