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

Reply via email to