<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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).</div><div><br>On 13 Jan 2017, at 02:57, Adriano Ferreira <<a href="mailto:adriano.ferreira@me.com">adriano.ferreira@me.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">Hi Dave,<div class=""><br class=""></div><div class="">I’m not arguing about correctness cause I understand the reasoning behind it, but about the abstraction itself.</div><div class=""><br class=""></div><div class="">I believe a simplified interface would be more fun to use and less confusing. <a href="https://oleb.net/blog/2016/10/generic-range-algorithms/" class="">This post</a> from Ole Begemann talks a little bit about this interesting idea.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">—A</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 12, 2017, at 5:55 PM, David Sweeris <<a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jan 12, 2017, at 15:44, Adriano Ferreira via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">BTW, I agree with you, having the range type split is somewhat confusing, specially for those new to the language.<br class=""></blockquote><br class="">Do you mean that you think having two types is confusing, or that the way we currently split them is confusing?<br class=""><br class="">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".<br class=""><br class="">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<br class=""> protocol Range<T> where T : WhateverTheCurrentConstraintsAre {<br class=""> var lower: T {get}<br class=""> var upper: T {get}<br class=""> }<br class="">Then we could define the concrete types as<br class=""> struct CCRange<T>: Range<T> {...}<br class=""> struct CORange<T>: Range<T> {...}<br class=""> struct OCRange<T>: Range<T> {...}<br class=""> struct OORange<T>: Range<T> {...}<br class="">(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<br class=""> var x = 0..<5 // "..<" returns `CORange as Range`<br class=""> x = 0...4 // "..." returns `CCRange as Range`, which is fine because x's type is `Range`, not `HalfOpenRange` (or whatever it's called now)<br class="">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.<br class=""><br class="">- Dave Sweeris <br class=""><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></body></html>