# Re: [swift-evolution] Range and ClosedRange

```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.ferre...@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 <daveswee...@mac.com> wrote:
>>>
>>>
>>> On Jan 12, 2017, at 15:44, Adriano Ferreira via swift-evolution
>>> <swift-evolution@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
>>
>
```
```_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
```